Banco de Dados

BANCO DE DADOS
CURSOS DE GRADUAÇÃO – EAD
Banco de Dados – Prof. Dr. Alexandre Leite Rangel, Profª Claudia Vicci Amadeu, Prof. Ms. Thiago Wellington Joazeiro de Almei-
da e Prof. Ms. Geraldo Henrique Neto
Meu nome é Alexandre Leite Rangel. Sou doutor e mestre pela Escola de Enfermagem de Ribeirão
Preto da Universidade de São Paulo (EERP/USP), na área de Informática na Saúde e na Enfermagem.
Minha formação é em Análise de Sistemas, com especialização na mesma área. Leciono a disciplina
Banco de Dados nos cursos de Sistemas de Informação e Licenciatura em Computação. Sou também
analista de sistemas do Hospital das Clínicas da Faculdade de Medicina de Ribeirão Preto da USP.
e-mail: alexandrerangel@claretiano.edu.br
Meu nome é Claudia Vicci Amadeu. Sou especialista em Análise de Sistemas com ênfase em Arquite-
tura Cliente-Servidor pela Pontifícia Universidade Católica de Campinas (PUC-Campinas) e graduada
em Análise de Sistemas. Atuo como docente no curso de Ciência da Computação da Universidade de
Franca (Unifran) e ministro as disciplinas de Modelagem de Sistemas, Banco de Dados e Engenharia de
Software.
e-mail: claudia_vicci@yahoo.com.br
Meu nome é Geraldo Henrique Neto. Sou mestre pela Faculdade de Medicina de Ribeirão Preto da
Universidade de São Paulo (FMRP/USP), na área de Informática Médica. Minha formação é em Ciência
da Computação, com especialização em Desenvolvimento Web pela Universidade Federal de São Car-
los (UFSCar). Leciono diversas disciplinas relacionadas a Banco de Dados em cursos de graduação da
FATEC Mococa, FAFRAM e UNIP de Ribeirão Preto. Sou também Consultor em Tecnologia da Informa-
ção em Ribeirão Preto e região.
e-mail: geraldohenrique@usp.br
Meu nome é Thiago Almeida. Sou mestre em Física Aplicada em Medicina e Biologia pela Universida-
de de São Paulo, especialista em Projetos de Circuitos Integrados Digitais pelo Instituto Eldorado e
graduado em Engenharia da Computação pela Universidade Federal de Itajubá-MG. Sou professor no
Claretiano – Centro Universitário nos cursos EaD de Computação.
e-mail: thiagoalmeida@claretiano.edu.br
Fazemos parte do Claretiano - Rede de Educação

Alexandre Leite Rangel
Claudia Vicci Amadeu
Geraldo Henrique Neto
Thiago Wellington Joazeiro de Almeida
BANCO DE DADOS
Batatais
Claretiano
2015
© Ação Educacional Claretiana, 2011 – Batatais (SP)
Versão: ago./2015
005.75 B161
Banco de dados / Alexandre Leite Rangel ... [et al.] – Batatais, SP : Claretiano, 2015.
278 p.
ISBN: 978-85-8377-386-3
1. Introdução aos Sistemas de Banco de Dados. 2. Modelo Entidade-Relacionamento.

3. Modelo de Dados Relacional. 4. SQL. 5. Álgebra Relacional. 6. Noções básicas
sobre Gerenciamento de Transação. 7. Controle de Concorrência. 8. Recuperação.
9. Segurança e distribuição de dados. I. Rangel, Alexandre Leite. II. Amadeu, Claudia
Vicci. III. Henrique Neto, Geraldo. IV. Almeida, Thiago Wellington Joazeiro de. V. Banco
de dados.
CDD 005.75
Corpo Técnico Editorial do Material Didático Mediacional

Coordenador de Material Didático Mediacional: J. Alves
Preparação Revisão
Aline de Fátima Guedes Cecília Beatriz Alves Teixeira
Eduardo Henrique Marinheiro
Camila Maria Nardi Matos Felipe Aleixo
Carolina de Andrade Baviera Filipi Andrade de Deus Silveira
Juliana Biggi
Cátia Aparecida Ribeiro
Paulo Roberto F. M. Sposati Ortiz
Dandara Louise Vieira Matavelli Rafael Antonio Morotti
Elaine Aparecida de Lima Moraes Rodrigo Ferreira Daverni
Sônia Galindo Melo
Josiane Marchiori Martins Talita Cristina Bartolomeu
Lidiane Maria Magalini Vanessa Vergani Machado
Luciana A. Mani Adami Projeto gráfico, diagramação e capa
Luciana dos Santos Sançana de Melo Eduardo de Oliveira Azevedo
Joice Cristina Micai
Patrícia Alves Veronez Montera Lúcia Maria de Sousa Ferrão
Raquel Baptista Meneses Frata Luis Antônio Guimarães Toloi
Raphael Fantacini de Oliveira
Rosemeire Cristina Astolphi Buzzelli
Tamires Botta Murakami de Souza
Simone Rodrigues de Oliveira Wagner Segato dos Santos
Todos os direitos reservados. É proibida a reprodução, a transmissão total ou parcial por qualquer forma
e/ou qualquer meio (eletrônico ou mecânico, incluindo fotocópia, gravação e distribuição na web), ou o
arquivamento em qualquer sistema de banco de dados sem a permissão por escrito do autor e da Ação
Educacional Claretiana.
Claretiano - Centro Universitário

Rua Dom Bosco, 466 - Bairro: Castelo – Batatais SP – CEP 14.300-000
cead@claretiano.edu.br
Fone: (16) 3660-1777 – Fax: (16) 3660-1780 – 0800 941 0006
www.claretianobt.com.br
Fazemos parte do Claretiano - Rede de Educação

SUMÁRIO
CADERNO DE REFERÊNCIA DE CONTEÚDO

1 INTRODUÇÃO............................................................................................................................................... 9
2 ORIENTAÇÕES PARA ESTUDO......................................................................................................................10
3 E-REFERÊNCIA.............................................................................................................................................. 20
4 REFERÊNCIA BIBLIOGRÁFICA .....................................................................................................................20
Unidade 1 – INTRODUÇÃO AOS SISTEMAS DE BANCO DE DADOS

1 OBJETIVOS.................................................................................................................................................... 21
2 CONTEÚDOS................................................................................................................................................. 21
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE ..........................................................................................21
4 INTRODUÇÃO À UNIDADE...........................................................................................................................23
5 DADOS VERSUS INFORMAÇÕES..................................................................................................................24
6 SISTEMAS DE ARQUIVOS VERSUS SGBDS..................................................................................................27
7 DADOS EM SGBDS: DESCRIÇÃO E ARMAZENAMENTO.............................................................................31
8 ARQUITETURA EM UM SGBD......................................................................................................................45
9 CONSULTAS EM UM SGBD...........................................................................................................................48
10 Q UESTÕES AUTOAVALIATIVAS....................................................................................................................49
11 C ONSIDERAÇÕES ......................................................................................................................................... 50
12 E-REFERÊNCIAS............................................................................................................................................ 50
13 R EFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................50
Unidade 2 – MODELAGEM DOS DADOS UTILIZANDO O MODELO ENTIDADE-RELACIONAMENTO

1 OBJETIVOS.................................................................................................................................................... 51
2 CONTEÚDOS................................................................................................................................................. 51
5 MODELOS DE BANCO DE DADOS................................................................................................................52
6 DEFINIÇÕES DE OBJETOS DO MODELO ENTIDADE-RELACIONAMENTO (MER)......................................54
7 CARACTERÍSTICAS ADICIONAIS DO MODELO ENTIDADE-RELACIONAMENTO.......................................64
8 PROJETO CONCEITUAL DE BANCO DE DADOS COM O MODELO ENTIDADE-RELACIONAMENTO........64
9 DIAGRAMA ENTIDADE-RELACIONAMENTO (DER)....................................................................................66
10 E XEMPLOS DE DIAGRAMAS ENTIDADE-RELACIONAMENTO....................................................................67
11 M ODELO ENTIDADE-RELACIONAMENTO ESTENDIDO (EER)....................................................................69
13 C ONSIDERAÇÕES.......................................................................................................................................... 74
Unidade 3 – MODELO DE DADOS RELACIONAL

1 OBJETIVO...................................................................................................................................................... 75
2 CONTEÚDOS................................................................................................................................................. 75
5 MODELO RELACIONAL................................................................................................................................. 76
6 NOTAÇÃO DO MODELO RELACIONAL.........................................................................................................81
7 ATRIBUTOS-CHAVE DE UMA RELAÇÃO.......................................................................................................82
8 ESQUEMA DE BANCO DE DADOS RELACIONAL.........................................................................................85
9 RESTRIÇÕES DE INTEGRIDADE SOBRE RELAÇÕES.....................................................................................86
10 O PERADORES DO CONJUNTO RELACIONAL..............................................................................................87
11 R ELACIONAMENTOS DENTRO DO BANCO DE DADOS RELACIONAL........................................................93
12 PROJETO LÓGICO DE BANCO DE DADOS: MAPEAMENTO DO MODELO ENTIDADE-RELACIONAMENTO
PARA O MODELO RELACIONAL...................................................................................................................98
14 C ONSIDERAÇÕES ......................................................................................................................................... 106
15 E-REFERÊNCIAS............................................................................................................................................ 107
Unidade 4 – SQL – UMA LINGUAGEM DE CONSULTA
1 OBJETIVOS.................................................................................................................................................... 109
2 CONTEÚDOS................................................................................................................................................. 109
5 LINGUAGEM SQL.......................................................................................................................................... 110
6 HISTÓRICO DO POSTGRESQL.......................................................................................................................112
7 PRINCIPAIS OPERAÇÕES PARA MANIPULAÇÃO DE DADOS......................................................................112
8 ESTRUTURA DA LINGUAGEM SQL – DML...................................................................................................128
9 ESTRUTURA DA LINGUAGEM SQL – DDL....................................................................................................184
10 I NTRODUÇÃO ÀS VISÕES ............................................................................................................................188
12 C ONSIDERAÇÕES.......................................................................................................................................... 194
13 E-REFERÊNCIA.............................................................................................................................................. 194
Unidade 5 – NORMALIZAÇÃO E DESEMPENHO EM SISTEMA DE BANCO DE DADOS

RELACIONAL
1 OBJETIVOS.................................................................................................................................................... 195
2 CONTEÚDOS................................................................................................................................................. 195
5 DEPENDÊNCIA FUNCIONAL DE UM BANCO DE DADOS RELACIONAL.....................................................196
6 NORMALIZAÇÃO........................................................................................................................................... 198
7 PROCESSO DE NORMALIZAÇÃO..................................................................................................................200
8 FATORES A SEREM CONSIDERADOS NO PROJETO FÍSICO DE BANCO DE DADOS RELACIONAL............209
9 QUESTÕES AUTOAVALIATIVAS....................................................................................................................214
10 C ONSIDERAÇÕES ......................................................................................................................................... 215
11 E-REFERÊNCIA.............................................................................................................................................. 215
12 R EFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................215
Unidade 6 – GERENCIAMENTO DE TRANSAÇÕES E CONTROLE DE CONCORRÊNCIA

1 OBJETIVOS.................................................................................................................................................... 217
2 CONTEÚDOS................................................................................................................................................. 217
5 POR QUE GERENCIAR UMA TRANSAÇÃO?.................................................................................................218
6 TRANSAÇÃO E IMPORTÂNCIA DO CONTROLE DE CONCORRÊNCIA.........................................................220
7 PROPRIEDADES DAS TRANSAÇÕES – ACID.................................................................................................222
8 FALHAS E A NECESSIDADE DE UMA RECUPERAÇÃO.................................................................................223
9 ESTADOS DE UMA TRANSAÇÃO..................................................................................................................224
10 P LANOS DE EXECUÇÃO DE TRANSAÇÕES...................................................................................................224
11 T ÉCNICAS DE BLOQUEIO PARA CONTROLE DE CONCORRÊNCIA.............................................................225
12 R EGRAS PARA O ESQUEMA DE BLOQUEIO COMPARTILHADO/EXCLUSIVO............................................226
13 D EADLOCK.................................................................................................................................................... 226
14 T IMESTAMPS................................................................................................................................................ 227
15 C ONTROLE DE CONCORRÊNCIA DE VALIDAÇÃO (OTIMISTA)...................................................................228
17 C ONSIDERAÇÕES.......................................................................................................................................... 229
Unidade 7 – RECUPERAÇÃO DE BANCO DE DADOS E SEGURANÇA 231

1 OBJETIVOS.................................................................................................................................................... 231
2 CONTEÚDOS................................................................................................................................................. 231
5 FUNÇÕES DE UM DBA ................................................................................................................................. 232
6 BACKUP E RECUPERAÇÃO...........................................................................................................................233
7 CACHING DE DISCO...................................................................................................................................... 234
8 TRANSAÇÕES: CHECKPOINTS, ROLLBACK..................................................................................................234
9 RECUPERAÇÃO BASEADA NA ATUALIZAÇÃO ADIADA...............................................................................235
10 R ECUPERAÇÃO BASEADA NA ATUALIZAÇÃO IMEDIATA...........................................................................235
11 PAGINAÇÃO SHADOW................................................................................................................................. 236
12 R ECUPERAÇÃO DE FALHAS EM BANCOS DE DADOS MÚLTIPLOS.............................................................236
13 R ECUPERAÇÃO DE FALHAS POR MOTIVOS DE CATÁSTROFE....................................................................236
14 S EGURANÇA DE DADOS............................................................................................................................... 237
15 M EDIDAS DE PROTEÇÃO AOS BANCOS DE DADOS...................................................................................240
17 C ONSIDERAÇÕES.......................................................................................................................................... 242
Unidade 8 – BANCO DE DADOS DISTRIBUÍDOS

1 OBJETIVOS.................................................................................................................................................... 243
2 CONTEÚDOS................................................................................................................................................. 243
5 POR QUE USAR BANCOS DE DADOS DISTRIBUÍDOS?...............................................................................246
6 PROCESSAMENTO DISTRIBUÍDO E BANCO DE DADOS DISTRIBUÍDO......................................................248
7 CLASSIFICAÇÃO DOS SGBDDS.....................................................................................................................252
8 CONSULTAS EM BANCO DE DADOS DISTRIBUÍDO.....................................................................................253
9 TRANSAÇÕES DISTRIBUÍDAS.......................................................................................................................253
10 C ONTROLE DE CONCORRÊNCIA E DE RECUPERAÇÃO...............................................................................254
12 C ONSIDERAÇÕES FINAIS.............................................................................................................................. 255
APÊNDICE 1...................................................................................................................................................... 257

APÊNDICE 2...................................................................................................................................................... 270
Caderno de
Referência de
Conteúdo
CRC
Ementa–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Introdução aos Sistemas de Banco de Dados. Modelo Entidade-Relacionamento. Modelo de Dados Relacional. SQL.
Álgebra Relacional. Noções básicas sobre Gerenciamento de Transação, Controle de Concorrência, Recuperação,
Segurança e Distribuição de Dados.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
1. INTRODUÇÃO
Seja bem-vindo!
Você iniciará o estudo de Banco de Dados, a qual fornecerá a você conteúdos específicos
para a projeção de bancos de dados. Para facilitar sua compreensão, o conteúdo foi segmentado
em oito unidades.
Além disso, você terá a oportunidade de conhecer conceitos fundamentais para a elabora-
ção e a construção de bancos de dados, como o projeto conceitual, o projeto lógico e o projeto
físico, e a manipulação e a manutenção de bancos de dados por meio de linguagem SQL básica
e avançada.
Outro aspecto relevante para o desenvolvimento de banco de dados bem estruturados é a
aplicação da normalização, tema estritamente relacionado ao desempenho (acesso aos dados).
Com o conteúdo estudado, além de criar bancos de dados estruturados, você saberá aplicar as
fases de normalização até a 4ª forma normal.
Além disso, é imprescindível que você, como administrador de bancos de dados, acompa-
nhe a evolução dos Sistemas Gerenciadores de Bancos de Dados (SGBDs), não tomando apenas
esta obra como fonte de aprendizagem. É importante que você complemente sua formação
10 © Banco de Dados
consultando outras fontes, como livros, revistas e páginas web. Não se esqueça de compartilhar
suas experiências por meio dos Fóruns e da Lista na Sala de Aula Virtual, pois, assim, você não só
contribuirá para o aprendizado de outras pessoas, mas também solidificará seu conhecimento.
Após essa introdução aos conceitos principais, apresentaremos, a seguir, no Tópico Orien-
tações para estudo, algumas orientações de caráter motivacional, dicas e estratégias de apren-
dizagem que poderão facilitar seu estudo.
2. ORIENTAÇÕES PARA ESTUDO
Abordagem Geral
Prof. Ms. Geraldo Henrique Neto
Neste tópico, apresenta-se uma visão geral do que será estudado. Aqui, você entrará em
contato com os assuntos principais deste conteúdo de forma breve e geral e terá a oportunidade
de aprofundar essas questões no estudo de cada unidade. Desse modo, essa Abordagem Geral
visa fornecer-lhe o conhecimento básico necessário a partir do qual você possa construir um
referencial teórico com base sólida – científica e cultural – para que, no futuro exercício de sua
profissão, você a exerça com competência cognitiva, ética e responsabilidade social.
Banco de Dados tem como objetivo principal sua iniciação na elaboração e na construção
de bancos de dados, no qual você conhecerá as fases constituintes de um projeto bem estrutu-
rado de banco de dados, como também terá contato com a linguagem SQL.
Antes de iniciar o estudo sobre banco de dados, é importante definir o que é um banco
de dados. Pois bem, o banco de dados se constitui em um sistema de armazenamento de da-
dos cujo objetivo é registrar e salvaguardar informações relevantes que poderão ser acessadas
quando necessário. Os bancos de dados são amplamente utilizados e constituem a parte essen-
cial de quase todas as empresas, independentemente do seu ramo de atividade. A importância
dos bancos de dados foi impulsionada nos últimos anos devido ao crescimento das aplicações
web, das implantações de ERP's (Enterprise Resourcing Process), de BI (Businnes Intelligence),
dentre outras. Todas essas tecnologias são dependentes do banco de dados por envolverem ar-
mazenamento de grandes volumes de dados, recuperação de dados no menor tempo possível,
segurança de acesso, backup de dados em tempo real, dentre outras funcionalidades.
Conforme comentado, o banco de dados é extremamente importante para o armaze-
namento de dados. Mas, afinal, qual a definição de dados? Existe diferença entre dados e in-
formações? Para o bom entendimento, é fundamental entender a diferença entre esses dois
conceitos. Os dados são considerados fatos brutos, o que indica que os fatos ainda não foram
processados para revelar seu significado. Como exemplo, imagine que você queira saber o que
os usuários de um laboratório de informática pensam a respeito do serviço prestado. Normal-
mente, você começaria entrevistando os usuários para avaliar o desempenho do laboratório.
Você poderia usar um formulário na web, o que permitiria que os usuários respondessem as
suas questões. Quando o formulário estiver preenchido, os dados, nesse exato momento, são
considerados como brutos, armazenados em um repositório de dados. Embora você já tenha os
fatos em mãos, eles não possuem nenhuma utilidade específica nesse formato. Portanto, é ne-
cessário transformar os dados brutos em dados lapidados, permitindo obter respostas rápidas e
objetivas das questões oriundas do formulário, como: "Qual é a composição da base de clientes
de nosso laboratório?".
© Caderno de Referência de Conteúdo 11
Para revelar seu significado, os dados brutos são processados de maneira apropriada, ge-
rando, assim, as informações. Esse processamento pode ser considerado simples (como exem-
plo podemos citar a organização dos dados para extrair padrões) ou complexo (como a realiza-
ção de estimativas, empregando variáveis estatísticas). As informações necessitam conhecer seu
contexto para revelar seu significado adequado.
As informações são consideradas fundamentais para a tomada de decisão nas empresas,
seja governamental, de serviços ou filantrópicas. Um resumo dos dados extraídos das questões
referentes a cada formulário de entrevista pode demonstrar os pontos fortes e fracos de um
serviço, por exemplo, e auxiliar na tomada de decisões para melhor atender às necessidades de
seus clientes.
Você já ouviu falar em FAT, FAT32, NTFS, SQL Server, Oracle e MySQL? Todas essas siglas
têm um objetivo em comum: organizar e armazenar dados em sistemas computacionais. Elas
fazem parte de dois sistemas para controle de informação: Sistema de Arquivos e Sistema Ge-
renciador de Banco de Dados (SGBD).
Sistema de arquivos é o método de organizar e armazenar informações seguindo uma es-
trutura lógica para alocação física dos arquivos em dispositivos de armazenamento, tais como:
disco rígido ou CD-ROM. Em outras palavras, o sistema de arquivos é a estrutura que indica
como os arquivos devem ser gravados e guardados em algum sistema de armazenamento.
Já, o SGBD é uma coleção de programas que permite ao usuário definir, construir e ma-
nipular bases de dados para as mais diversas finalidades. Os programas ou softwares SGBDs
mais conhecidos são Microsoft SQL Server, MySQL, Oracle, FireBird e PostgreSQL. No Sistema
Gerenciador de Banco de Dados, o acesso aos dados e o seu gerenciamento são realizados pelo
próprio SGBD, o qual funciona como uma interface entre o banco de dados e os programas apli-
cativos, isto é, o SGBD está localizado entre o banco de dados físico e os usuários.
Um modelo de banco de dados nada mais é do que uma descrição dos tipos de informa-
ções que serão armazenadas em um banco de dados. Para que possamos construir um modelo
de dados é necessário o uso de uma linguagem de modelagem de dados. Essas linguagens são
classificadas em linguagens textuais ou gráficas. Cada representação de um modelo de dados
por meio de uma linguagem de modelagem de dados recebe a denominação de esquema de
banco de dados.
Em um projeto de banco de dados, comumente são utilizados dois níveis de abstração,
sendo eles: o modelo conceitual e o modelo lógico. Um modelo conceitual é uma descrição do
banco de dados de forma independente de implementação em um SGBD. O modelo conceitual
registra quais dados podem aparecer no banco de dados, mas não registra como estes dados
serão armazenados em nível do SGBD.
A técnica de modelagem conceitual mais difundida é a abordagem entidade-relaciona-
mento (ER). Utilizando-se esta técnica, um modelo conceitual é usualmente representado por
meio de um diagrama, denominado diagrama entidade-relacionamento (DER).
Um modelo lógico é uma descrição de um banco de dados no nível de abstração visto pelo
usuário do SGBD, de forma que este modelo é dependente do SGBD que será usado. Em um
modelo lógico devem ser definidas quais as tabelas contidas pelo banco e, para cada tabela, os
nomes das colunas.
No decorrer das unidades, veremos que o minimundo representa o domínio relacionado
aos dados que o banco deve armazenar. Um levantamento dos requisitos desse minimundo é

efetuado e, a partir da análise de requisitos, é criado o projeto conceitual, representado pelo

modelo entidade-relacionamento, o qual não contém detalhes de implementação, tratando-se,
portanto, de um modelo de dados de alto nível, e independente do SGBD a ser adotado. O pró-
ximo passo, diz respeito à criação do projeto lógico, que é realizada por meio do mapeamento
do modelo entidade-relacionamento para o modelo relacional. A partir dessa fase, você já pode
pensar em um modelo de dados de implementação do SGBD. E, para finalizar, o último passo
corresponde à fase nomeada de projeto físico, quando são definidos as estruturas de armaze-
namento interno, os índices, além de outras atividades desenvolvidas paralelamente, tal como
a implementação dos programas de aplicação.
Você já ouviu falar em modelo entidade-relacionamento? Pois bem, o modelo entidade-
-relacionamento (MER) foi criado por Peter Chen na década de 1970, podendo ser considerado
um padrão para a modelagem conceitual. Esse modelo é baseado na percepção do mundo real,
e tem como finalidade a construção de objetos denominados entidades e a promoção o relacio-
namento entre eles.
O MER tem a intenção de descrever, de maneira conceitual, os dados que serão utilizados
em um sistema de informação. Essa descrição acontece na fase conceitual do projeto de banco
de dados e será utilizada pelo sistema de informação em questão. O modelo possui conceitos
intuitivos que permitem aos projetistas de bancos de dados capturarem os conceitos inerentes
aos dados da aplicação, independente de qualquer tecnologia utilizada para desenvolvimento
de bancos de dados. O esquema conceitual criado utilizando-se os conceitos do modelo entida-
de-relacionamento é denominado de diagrama entidade-relacionamento (DER).
O diagrama entidade-relacionamento é composto por entidades, atributos e relaciona-
mentos. As entidades representam objetos do mundo real; os atributos representam suas ca-
racterísticas; e os relacionamentos representam a forma como esses objetos estão ligados entre
si. Uma entidade é um objeto existente e distinto de qualquer outro objeto. Sua finalidade é
representar um conjunto de objetos da realidade modelada. Por exemplo, uma pessoa chamada
de José Ribeiro Neves possui um número de CPF único, CPF nº 123.321.987-00; este número de
CPF é uma entidade, uma vez que identifica a pessoa de uma forma única em relação às outras
pessoas. Uma entidade pode ser concreta, como uma pessoa ou uma empresa, ou abstrata,
como um conceito.
Dessa maneira, você pode perceber que um conjunto de entidades é um grupo de entida-
des do mesmo tipo. O conjunto de alunos de sua turma, por exemplo, pode ser definido como o
conjunto de entidades ALUNOS. A representação gráfica de uma entidade é obtida por meio de
um retângulo identificado por um nome da entidade.
Uma das propriedades sobre as quais pode ser desejável manter associações é a asso-
ciação entre objetos. Por exemplo, você pode achar válido conhecer apenas as pessoas de um
determinado departamento. Entretanto, uma pessoa teria que estar associada/vinculada a um
departamento para que esta classificação obtenha êxito. Um relacionamento não ocorre, neces-
sariamente, entre entidades diferentes, podemos notar a existência do autorrelacionamento,
ou seja, um relacionamento entre ocorrências de uma mesma entidade. Um detalhe importante
em um autorrelacionamento é a identificação e compreensão do conceito de papel da entidade
no relacionamento. Esse papel de entidade em relacionamento exerce a função que uma instân-
cia da entidade cumpre dentro de uma instância do relacionamento.
Você já deve ter percebido que um diagrama entidade-relacionamento pode definir n res-
trições com as quais o banco de dados deve estar de acordo. Uma dessas restrições é a cardina-
lidade do mapeamento, que expressa o número de entidades relacionadas a outras entidades

por meio de um conjunto de relacionamentos. Basicamente, existem três tipos de relaciona-
mentos entre entidades binárias: um-para-um (uma entidade de A está associada a apenas uma
entidade de B, e uma entidade de B está associada a apenas uma entidade de A), um-para-
-muitos (uma entidade de A está associada a muitas entidades de B, entretanto, uma entidade
de B está associada a apenas uma entidade de A), muitos-para-muitos (uma entidade de A está
associada a qualquer quantidade de entidades de B, e uma entidade de B está associada a qual-
quer número de entidades de A).
Não nós limitamos apenas aos relacionamentos e seus atributos, podemos ainda abstrair-
mos propriedades à entidades por meio do uso do conceito de generalização/especialização.
Isso nos permite atribuir propriedades específicas a um subconjunto de ocorrências (especiali-
zação) de uma entidade considerada genérica. Para exemplificar o conceito de generalização/
especialização, imagine que a entidade CLIENTE seja segmentada em dois subconjuntos, esses
representados pelas entidades nomeadas respectivamente de PESSOA FÍSICA e PESSOA JURÍDI-
CA, em que cada uma possui propriedades específicas. A aplicação da generalização/especiali-
zação implica que a entidade PESSOA FÍSICA, além de possuir suas características específicas,
possui também todas aquelas contidas na entidade CLIENTE, ou seja, a entidade PESSOA FÍSICA
possui os seguintes atributos: CPF, sexo, nome e código, sendo os dois últimos provenientes da
entidade genérica CLIENTE. De modo similar, a entidade PESSOA JURÍDICA possui os seguintes
atributos: CGC, tipo de organização, bem como o nome e código, sendo estes, oriundos da en-
tidade CLIENTE.
Vimos que um relacionamento é uma associação entre entidades, certo? Na modelagem
ER não foi prevista a possibilidade de associar uma entidade a um relacionamento, ou então, de
associar dois relacionamentos entre si. Na prática, quando construímos um novo DER ou modi-
ficamos um DER existente, surgem situações em que se deseja flexibilizar a associação de uma
entidade a um relacionamento. Uma entidade associativa nada mais é que a redefinição de um
relacionamento, que passa a ser tratado como se fosse também uma entidade.
A linguagem SQL (Structured Query Language) não é uma linguagem de programação de
computadores criada com o propósito de desenvolver sistemas, como as linguagens Pascal, C,
Basic, Cobol, Java, C/C++, C#, dentre outras. É uma linguagem declarativa, cuja finalidade é fa-
cilitar o acesso às informações por meio de consultas, atualizações e manipulações de dados
armazenados em bancos de dados relacionais.
Devido a sua boa aceitação no mercado, surgiram os primeiros problemas operacionais,
pois cada empresa passou a incorporar funcionalidades e comandos próprios à linguagem SQL,
diferenciando-a da sua forma original. Na tentativa de reduzir esses problemas, surge, nesse ce-
nário, o ANSI (American National Standards Institute), o qual passou a estabelecer, por meio de
um Comitê, normativas e critérios para definição de padrões para a linguagem SQL, que a partir
desse período começou a ser referenciada por ANSI/SQL.
Apesar dos inúmeros esforços de entidades e institutos de padronização para construir
um padrão de trabalho adequado, infelizmente, ainda existem empresas que implementam ro-
tinas, funções e comandos totalmente fora do padrão estabelecido, dificultando a vida dos pro-
fissionais da área de Tecnologia da Informação (TI). Em alguns casos isolados, utilizam mais de
um Sistema de Gerenciamento de Banco de dados em um mesmo ambiente operacional.
A linguagem SQL utilizada no SGBD PostgreSQL é segmentada em quatro subconjuntos
que formam a base das instruções: DDL (Data Definition Language), DML (Data Manipulation

Language), DCL (Data Control Language) e DQL (Data Query Language) – podendo, ainda, in-
cluir os subconjuntos SRC (Stored Routines Commands).
O subconjunto DDL (Data Definition Language) oferece recursos para definir objetos e con-
trolar os dados. São comandos responsáveis pela estruturação do banco de dados, por exemplo:
a criação do próprio banco de dados (database), a criação das tabelas, dos índices, entre outros
objetos. Você utilizará a maioria dos comandos que constituem a DDL, como: CREATE TABLE,
CREATE VIEW, CREATE DATABASE, entre outros, durante este estudo.
Já, o subconjunto DML (Data Manipulation Language) tem como objetivo promover me-
canismos para manipulação e gerenciamento dos bancos de dados, inserindo, alterando e re-
movendo os dados. Os comandos que formam esse subconjunto são: DELETE, INSERT, UNION e
UPDATE.
No que se refere ao controle de acesso aos dados, o DCL (Data Control Language) oferece
recursos de controle de acesso de usuários ao sistema e aos dados, promovendo regras para
realização de consultas, inserções, modificações e exclusões de dados do banco de dados. Essa
linguagem é formada por comandos como GRANT e REVOKE, entre outros.
O comando SELECT faz parte da DQL (Data Query Language), considerado por alguns auto-
res como um comando pertencente ao subconjunto DML (Data Manipulation Language).
Os SRC (Stored Routines Commands) são comandos que permitem a utilização de códigos
de sub-rotinas armazenados no SGBD formados por AFTER, AS, BEFORE, BEGIN, CALLED, CREA-
TE, DECLARE, entre outros.
E por fim, o DTC (Data Type Commands) é o grupo de comandos responsáveis por estabe-
lecer o tipo de dado que uma coluna armazenará em uma tabela específica. O DTC é formado
pelos comandos BIGINT, BIGSERIAL, CHAR, CHARACTER, DATE, DECIMAL, DOUBLE, INTEGER, INT,
MONEY, NUMERIC, entre outros.
Além dos comandos descritos anteriormente, existe um conjunto de funções predefini-
das, com uma série de operadores, que promovem facilitadores nas diversas ações realizadas
pelos aplicativos.
Antes mesmo de você explorar as fases de normalização de um banco de dados, você de-
verá conhecer as restrições de integridade conhecidas como dependências funcionais. A norma-
lização está relacionada intimamente com aspectos importantes como desempenho do banco
de dados.
Segundo Takai; Italiano e Ferreira (2005), a dependência funcional:
[...] é uma propriedade do significado ou semântica dos atributos em um esquema de relação R. Utiliza-
-se o entendimento da semântica de atributos de R, isto é, como eles se relacionam, para especificar as
dependências funcionais envolvidas em todas as instâncias da relação r (extensão) de R. As instâncias
r satisfazem as restrições legais, pois obedecem as restrições de dependência funcional. Assim, a prin-
cipal utilização das dependências funcionais é a de descrever um esquema de relação R especificando
restrições sobre seus atributos que devem ser validados todas às vezes.
A função da normalização é atuar como um filtro sobre as entidades e os relacionamentos,

eliminando alguns elementos sem causar perda de informação nas entidades e nas relações.
No decorrer deste estudo, você verá como isso é realizado por meio das formas normais, as
quais foram introduzidas para atuar em cada caso em que a informação se encontra disponível
para ser tratada, deixando os dados mais bem organizados dentro de um banco de dados. Ao
aplicarmos a normalização, deseja-se evitar: grupos repetitivos de dados; variação temporal de
certos atributos, dependências funcionais totais ou parciais em relação a uma chave concate-
nada; redundâncias de dados desnecessários; perdas acidentais de informação; dificuldade na

representação de fatos da realidade observada e dependências transitivas entre atributos.
A normalização tem sua atuação por meio das formas normais. Os primeiros estágios do
processo de normalização são: primeira forma normal (1FN), segunda forma normal (2FN) e
terceira forma normal (3FN). Nesses três estágios, sob um ponto de vista estrutural, a forma
normal maior apresenta-se melhor sobre sua antecessora, logo a 3FN é melhor que a 2FN, que
por sua vez é melhor que a 1FN.
Embora a normalização seja de grande relevância para o sucesso de um Projeto de Banco
de Dados, não devemos assumir que seu nível alto seja sempre o mais adequado a se utilizar. O
êxito do projeto dá-se, mediante a análise da demanda do usuário para com um desempenho
satisfatório.
O objetivo da normalização é garantir que todas as tabelas atendam ao conceito de re-
lações bem estabelecidas, ou seja, que tenham as seguintes características: cada tabela deve
apresentar um único assunto, por exemplo, uma tabela de disciplina deverá possuir apenas as
informações pertinentes à disciplina; nenhum item de dado deverá ser armazenado de forma
desnecessária em mais de uma tabela, como mencionado anteriormente, a redundância, se
houver necessidade desta, deve ser minuciosamente controlada; todos os atributos não perti-
nentes à tabela deverão ser dependentes da chave primária, garantindo assim a identificação
exclusiva dos dados; e, para finalizar, todas as tabelas deverão estar livres das anomalias (ano-
malias de atualização, inserção e exclusão), de modo a garantir a integridade e a consistência
dos dados.
Uma relação se encontra na primeira forma normal (1FN) se todos os seus atributos são
monovalorados e atômicos. Entretanto, se utilizarmos a 1FN e a tabela resultante possuir chave
primária com apenas um atributo, a tabela está automaticamente na 2FN.
Semelhante ao processo de normalização, um modelo antes de ser convertido à terceira
forma normal (3FN) deve, primeiro, estar enquadrado na 2FN. Existe uma forma normal mais
restritiva do que a 3FN, que é a forma normal de Boyce-Codd (BCNF), a qual foi proposta como
uma forma mais simples que a 3FN. A BCNF é considerada mais restritiva, pois, à medida que
toda relação está na BCNF, também estará na 3FN; entretanto, o inverso não é considerado ver-
dadeiro.
É desejável que um projeto de banco de dados alcance a 3FN ou BCNF para todo esquema
da relação. Alcançar o status de normalização somente na 1FN ou na 2FN não é considerado
adequado, uma vez que essas formas foram desenvolvidas como caminho para a 3FN. Uma
tabela é dita na 3FN se, e somente se, estiver na 2FN e não possuir, em hipótese alguma, depen-
dências transitivas.
Não podemos pensar em um banco de dados como um sistema único, pois, dificilmente,
ele fica isolado em uma máquina e é acessado apenas por uma pessoa, ou de apenas um lugar.
Ao pensar em banco de dados, devemos ter em mente que informações armazenadas podem
ser acessadas por muitas pessoas, as quais podem, ainda, estar em locais diferentes.
Em uma instituição financeira, como os muitos bancos que temos espalhados pelo Brasil
(considerando apenas o território nacional), você pode ter uma conta que foi aberta em deter-
minada agência, mas pode fazer as operações bancárias a partir de qualquer local em que haja
um caixa eletrônico dessa instituição financeira.

Além disso, você pode ter uma conta com outra pessoa, isto é, duas pessoas podem fazer
as mesmas operações na mesma conta bancária. Se ambas, a partir de lugares diferentes, resol-
verem fazer um saque, no mesmo momento, da mesma conta corrente, quem sacará primeiro?
O usuário poderia receber uma informação incorreta e, muitas vezes, sem lógica.
Para que não ocorra esse caos no sistema, existe a transação, que é uma unidade de exe-
cução de programa que acessa e, possivelmente, atualiza vários itens de dados.
Analisando do ponto de vista do SGBD, uma transação é uma sequência de operações que
são tratadas como um bloco único e indivisível (atômico), quanto à sua recuperação, ou seja, a
execução parcial de transações não é permitida.
As responsabilidades do DBA variam a cada organização, mas, de modo geral, o DBA de-
verá planejar a estratégia de administração de dados. Sua função, de modo direto, consiste em
definir, implementar e aplicar as políticas, padrões e procedimentos pertinentes a uma melhor
conduta para o zelo das informações contidas em um banco de dados.
Sabe-se que um dos maiores ativos das organizações é o seu contingente informacional, e
quando uma organização necessita acessar determinada informação que não está prontamente
disponível, perdas podem ser geradas. Por isso, procedimentos de backup e restauração são im-
prescindíveis para assegurar a proteção e a constante disponibilidade das informações obtidas e
acumuladas ao longo do tempo.
Os procedimentos de backup e restauração são muito importantes em qualquer SGBD uti-
lizado. O DBA em questão deve garantir que os dados possam ser recuperados totalmente em
caso de perda física ou de integridade dos dados.
As atividades do DBA inclui o gerenciamento de desastres, de modo a garantir a disponi-
bilidade dos dados após um possível desastre, seja ele físico ou uma falha de integridade. Para
tanto, é necessário um planejamento sistêmico dentro da organização, o que deverá compreen-
der planos de testes e planejamento de ações, procedimentos necessários à recuperação.
A computação distribuída pode ser aplicada não somente a banco de dados, mas a quais-
quer componentes que se encontram em computadores ou em locais diferentes e que, de algu-
ma forma, se relacionam.
Um sistema de computação distribuída pode ser entendido como vários componentes
que estão ligados por uma rede de computadores e que se relacionam para executarem tarefas
em comum.
Segundo Elmasri e Navathe (2005, p. 579), banco de dados distribuídos pode ser definido
como "uma coleção de múltiplos bancos de dados logicamente inter-relacionados, distribuídos
por uma rede de computadores".
Um Sistema de Gerenciamento de Banco de Dados Distribuídos (SGBDD) tem por finalida-
de controlar o armazenamento e processamento de dados relacionados logicamente por meio
de sistemas computacionais interconectados. Neste contexto, tanto os dados como as funções
de processamento são distribuídos entre os diversos locais, também nomeados, eventualmen-
te, de nós.
Bem, chegamos ao final de nossa abordagem e esperamos que você tenha aproveitado
ao máximo os tópicos aqui apresentados, mesmo que de forma sucinta. É importante destacar
que apenas o estudo teórico da linguagem SQL não será suficiente para o seu aprendizado: é
fundamental que você pratique exaustivamente! Para tanto, crie o cenário instalando o SGBD
PostgreSQL, conforme orientações descritas no Apêndice 1.
Glossário de Conceitos
O Glossário de Conceitos permite a você uma consulta rápida e precisa das definições con-
ceituais, possibilitando-lhe um bom domínio dos termos técnico-científicos utilizados na área de
conhecimento dos temas tratados em Banco de Dados. Veja, a seguir, a definição dos principais
conceitos:
1) Atributo: abstração de uma propriedade de uma entidade ou de um relacionamento.
2) Banco de Dados: sistema de armazenamento de dados cujo objetivo é registrar e
guardar informações importantes que poderão ser acessadas quando necessário.
3) Banco de Dados Espaciais: aquele que permite consultar objetos localizados em um
espaço multidimensional. É o caso dos bancos de dados geográficos, que armazenam
informações sobre mapas para localização de rios, cidades, estados, estradas, entre
outros.
4) Banco de Dados Especialistas: também conhecido como sistemas baseados em co-
nhecimento, é aquele que, por meio de técnicas aplicadas na área da Inteligência Ar-
tificial, incorpora raciocínio e inferência (capacidade de dedução).
5) Banco de Dados Meteorológicos: banco que armazena informações sobre o tempo.
6) Banco de Dados Multimídias: banco que armazena os dados sob a forma de imagem,
clipes de filmes, músicas, textos falados ou escritos, entre outros.
7) Banco de Dados Temporais: é aquele que permite ao usuário consultar estados atuais
e passados do banco de dados, pois armazena históricos das alterações.
8) Base de Dados: representado por um conjunto de banco de dados. Base de dados e
banco de dados não são sinônimos.
9) BI (Business Intelligence ou Inteligência de Negócios): utiliza conceitos em que as
informações são coletadas, armazenadas e analisadas, tendo como base fatos reais
e/ou hipóteses. Esses sistemas auxiliam na gestão organizacional e no processo de
tomada de decisões.
10) Dado atômico: tipo de dado considerado básico, ou seja, indivisível.
11) Dado não atômico: tipo de dado considerado complexo, divisíveis (fragmentados).
12) Entidade: abstração de um fato do mundo real para o qual se deseja manter seus da-
dos no banco de dados.
13) ERP’s: são sistemas de gestão empresarial que possibilitam a integração de todos os
dados e processos de uma empresa, melhorando o fluxo de informações.
14) Gerenciamento de Banco de Dados: utiliza Sistemas Gerenciadores de Banco de Da-
dos (SGBDs).
15) Gerenciamento de Base de Dados: utiliza ferramentas de apoio integradas à tomada
de decisão organizacional (ERP – Enterprise Resource Planning) ou Datawarehouse.
16) Integridade Semântica: garantia de dados sempre corretos com relação ao domínio
de aplicação.
17) Modelagem Conceitual: nível mais alto de abstração cujo objetivo é representar os
requisitos de dados do domínio da aplicação (independente do modelo de banco de
dados).
18) Modelagem Física: constitui um esquema SQL para a modelagem lógica (depende
exclusivamente do SGBD).
19) Modelagem Lógica: representação da modelagem conceitual em um modelo de ban-
co de dados.
20) Relacionamento: abstração de uma associação entre (ocorrências de) entidades.
21) Sistema Gerenciador de Banco de Dados (SGBD): coleção de programas responsáveis
pela criação e manutenção de banco de dados.

Esquema dos Conceitos-chave

Para que você tenha uma visão geral dos conceitos mais importantes deste estudo, apre-
sentamos, a seguir (Figura 1), um Esquema dos Conceitos-chave. O mais aconselhável é que
você mesmo faça o seu esquema de conceitos-chave ou até mesmo o seu mapa mental. Esse
exercício é uma forma de você construir o seu conhecimento, ressignificando as informações a
partir de suas próprias percepções.
É importante ressaltar que o propósito desse Esquema dos Conceitos-chave é representar,
de maneira gráfica, as relações entre os conceitos por meio de palavras-chave, partindo dos
mais complexos para os mais simples. Esse recurso pode auxiliar você na ordenação e na se-
quenciação hierarquizada dos conteúdos de ensino.
Com base na teoria de aprendizagem significativa, entende-se que, por meio da organiza-
ção das ideias e dos princípios em esquemas e mapas mentais, o indivíduo pode construir o seu
conhecimento de maneira mais produtiva e obter, assim, ganhos pedagógicos significativos no
seu processo de ensino e aprendizagem.
Aplicado a diversas áreas do ensino e da aprendizagem escolar (tais como planejamentos
de currículo, sistemas e pesquisas em Educação), o Esquema dos Conceitos-chave baseia-se,
ainda, na ideia fundamental da Psicologia Cognitiva de Ausubel, que estabelece que a apren-
dizagem ocorre pela assimilação de novos conceitos e de proposições na estrutura cognitiva
do aluno. Assim, novas ideias e informações são aprendidas, uma vez que existem pontos de
ancoragem.
Tem-se de destacar que "aprendizagem" não significa, apenas, realizar acréscimos na es-
trutura cognitiva do aluno; é preciso, sobretudo, estabelecer modificações para que ela se con-
figure como uma aprendizagem significativa. Para isso, é importante considerar as entradas de
conhecimento e organizar bem os materiais de aprendizagem. Além disso, as novas ideias e os
novos conceitos devem ser potencialmente significativos para o aluno, uma vez que, ao fixar
esses conceitos nas suas já existentes estruturas cognitivas, outros serão também relembrados.
Nessa perspectiva, partindo-se do pressuposto de que é você o principal agente da cons-
trução do próprio conhecimento, por meio de sua predisposição afetiva e de suas motivações
internas e externas, o Esquema dos Conceitos-chave tem por objetivo tornar significativa a sua
aprendizagem, transformando o seu conhecimento sistematizado em conteúdo curricular, ou
seja, estabelecendo uma relação entre aquilo que você acabou de conhecer com o que já fazia
parte do seu conhecimento de mundo (adaptado do site disponível em: <http://penta2.ufrgs.
br/edutools/mapasconceituais/utilizamapasconceituais.html>. Acesso em: 11 mar. 2010).
Como poderá observar, esse Esquema oferecerá a você, como dissemos anteriormente,
uma visão geral dos conceitos mais importantes deste estudo. Ao segui-lo, será possível transi-
tar entre os principais conceitos e descobrir o caminho para construir o seu processo de ensino-
-aprendizagem. Dentre esses conceitos, há o de Projeto de Banco de Dados, o qual implica o co-
nhecimento dos modelos conceitual, lógico e físico, além dos detalhes inclusos em cada modelo
mencionado.
Banco
de
Dados
Normalização
Projeto
de 1ª FN 2ª FN 3ª FN
Banco de Dados
Modelo Modelo
Conceitual Modelo Físico
Lógico
Cardinalidade
Entidade
Modelo Hierárquico Esquema
e XML SQL
Relacionamento Modelo Relacional

DDL
Atributos
Modelo Orientado a
Objetos
DML
DCL
Figura 1 Esquema dos Conceitos-chave de Banco de Dados.
O Esquema dos Conceitos-chave é mais um dos recursos de aprendizagem que vem se

somar àqueles disponíveis no ambiente virtual, por meio de suas ferramentas interativas, bem
como àqueles relacionados às atividades didático-pedagógicas realizadas presencialmente no
polo. Lembre-se de que você, aluno EaD, deve valer-se da sua autonomia na construção de seu
próprio conhecimento.
Questões Autoavaliativas
No final de cada unidade, você encontrará algumas questões autoavaliativas sobre os con-
teúdos ali tratados, as quais podem ser de múltipla escolha, abertas objetivas ou abertas dis-
sertativas.
Responder, discutir e comentar essas questões, bem como relacioná-las com a prática
do ensino de Banco de Dados pode ser uma forma de você avaliar o seu conhecimento. Assim,
mediante a resolução de questões pertinentes ao assunto tratado, você estará se preparando
para a avaliação final, que será dissertativa. Além disso, essa é uma maneira privilegiada de você
testar seus conhecimentos e adquirir uma formação sólida para a sua prática profissional.
Você encontrará, ainda, no final de cada unidade, um gabarito, que lhe permitirá conferir
as suas respostas sobre as questões autoavaliativas de múltipla escolha.
As questões de múltipla escolha são as que têm como resposta apenas uma alternativa correta. Por
sua vez, entendem-se por questões abertas objetivas as que se referem aos conteúdos matemáticos
ou àqueles que exigem uma resposta determinada, inalterada. Já as questões abertas dissertativas
obtêm por resposta uma interpretação pessoal sobre o tema tratado; por isso, normalmente, não há
nada relacionado a elas no item Gabarito. Você pode comentar suas respostas com o seu tutor ou com
seus colegas de turma.

Bibliografia Básica
É fundamental que você use a Bibliografia Básica em seus estudos, mas não se prenda só
a ela. Consulte, também, as bibliografias complementares.
Figuras (ilustrações, quadros...)

Neste material instrucional, as ilustrações fazem parte integrante dos conteúdos, ou seja,
elas não são meramente ilustrativas, pois esquematizam e resumem conteúdos explicitados no
texto. Não deixe de observar a relação dessas figuras com os conteúdos abordados, pois relacio-
nar aquilo que está no campo visual com o conceitual faz parte de uma boa formação intelectual.
Dicas (motivacionais)
Este estudo convida você a olhar, de forma mais apurada, a Educação como processo de
emancipação do ser humano. É importante que você se atente às explicações teóricas, práticas e
científicas que estão presentes nos meios de comunicação, bem como partilhe suas descobertas
com seus colegas, pois, ao compartilhar com outras pessoas aquilo que você observa, permite-
-se descobrir algo que ainda não se conhece, aprendendo a ver e a notar o que não havia sido
percebido antes. Observar é, portanto, uma capacidade que nos impele à maturidade.
Você, como aluno do curso de graduação na modalidade EaD, necessita de uma formação
conceitual sólida e consistente. Para isso, você contará com a ajuda do tutor a distância, do tutor
presencial e, sobretudo, da interação com seus colegas. Sugerimos, pois, que organize bem o
seu tempo e realize as atividades nas datas estipuladas.
É importante, ainda, que você anote as suas reflexões em seu caderno ou no Bloco de
Anotações, pois, no futuro, elas poderão ser utilizadas na elaboração de sua monografia ou de
produções científicas.
Leia os livros da bibliografia indicada, para que você amplie seus horizontes teóricos. Co-
teje-os com o material didático, discuta a unidade com seus colegas e com o tutor e assista às
videoaulas.
No final de cada unidade, você encontrará algumas questões autoavaliativas, que são im-
portantes para a sua análise sobre os conteúdos desenvolvidos e para saber se estes foram
significativos para sua formação. Indague, reflita, conteste e construa resenhas, pois esses pro-
cedimentos serão importantes para o seu amadurecimento intelectual.
Lembre-se de que o segredo do sucesso em um curso na modalidade a distância é parti-
cipar, ou seja, interagir, procurando sempre cooperar e colaborar com seus colegas e tutores.
Caso precise de auxílio sobre algum assunto, entre em contato com seu tutor. Ele estará
pronto para ajudar você.
3. E-REFERÊNCIA
TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J. E. Introdução a Banco de Dados. 2005. Disponível em: <http://pt.scribd.com/
doc/51228653/9/Arquiteturas>. Acesso em: 22 out. 2012.
4. REFERÊNCIA BIBLIOGRÁFICA
ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados. São Paulo: Pearson (Addison Wesley), 2005.
Introdução aos Sistemas de
Banco de Dados
1. OBJETIVOS
• Compreender o conceito básico de Sistemas Gerenciadores de Bancos de Dados (SGBD),
sua importância, utilização e aplicação.
• Conhecer os SGBDs mais utilizados no mercado, os problemas de armazenamento e
recuperação de dados (redundâncias, inconsistências, integridade, compartilhamento
e segurança) e os requisitos básicos que devem ser atendidos para um bom desempe-
nho.
2. CONTEÚDOS
• Perspectiva histórica.
• Sistemas de arquivos versus SGBDs.
• Dados em SGBDs: descrição e armazenamento.
• Arquitetura em um SGBD.
• Consultas em um SGBD.
3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE

Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Tenha sempre à mão o significado dos conceitos explicitados no Glossário e suas liga-
ções pelo Esquema de Conceitos-chave para o estudo de todas as unidades deste CRC.
Isso poderá facilitar sua aprendizagem e seu desempenho.
2) É importante que você fique sempre atento às informações contidas na unidade. Pro-
grame-se, organize seus estudos e participe ativamente na Sala de Aula Virtual. Ser
disciplinado para estudar pode ajudar você a tirar o máximo de proveito em seu curso
de Educação a Distância.
3) Antes de iniciar os estudos desta unidade, pode ser interessante conhecer um pouco
sobre a evolução das formas de armazenamento de dados. Para saber mais, acesse os
sites indicados nas E-referências.
4) O início do estudo desta unidade envolve alguns aspectos teóricos que serão funda-
mentais ao longo de todo o aprendizado. Dessa maneira, faça uso de um bloco de
anotações para destacar os principais conceitos, tais como: banco de dados, dados
e informações, sistemas de arquivos, Sistemas Gerenciadores de Bancos de Dados
(SGBD) etc.
5) Lembre-se que dado é o que está armazenado no banco de dados e informação é o
significado dos dados.
6) O best-seller O mundo é plano, de Thomas Friedman, mostra que, devido ao avanço
tecnológico, uma informação inédita é disponibilizada para o mundo todo em segun-
dos, colocando em igualdade de conhecimento populações de países desenvolvidos
e países em desenvolvimento. Reflita sobre a importância dos dados e seu armazena-
mento no mundo globalizado.
7) Os conceitos apresentados nesta unidade serão trabalhados na prática nas unidades
seguintes. Preocupe-se, a princípio, em compreender as diferenças entre os conceitos
apresentados. Se necessário, anote os termos e suas definições em um caderno para
retomá-los posteriormente.
Perspectiva Histórica–––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Em algum momento da história, as empresas descobriram que estava muito caro empregar um número grande de
pessoas para fazer certos trabalhos, como armazenar e indexar (organizar) arquivos. Por este motivo, valia a pena
empregar esforços e investir em pesquisas em busca de um meio mais barato e uma solução mecânica eficiente.
Na década de 1970, Ted Codd, um pesquisador renomado da IBM, publicou o primeiro artigo
referente a bancos de dados relacionais. Este artigo discorria sobre o uso de cálculo e álgebra
relacional, recursos que possibilitavam que usuários não técnicos manipulassem grande
quantidade de informações. Codd projetava em sua mente um sistema computacional em que
fosse factível ao usuário acessar os dados armazenados em tabelas através de comandos
específicos. Na época, ninguém percebeu que as teorias obscuras de Codd desencadeariam
uma revolução tecnológica comparável ao desenvolvimento dos computadores pessoais e da
internet. Don Chamberlin, coinventor da SQL, a mais popular linguagem de computador utili-
zada pelos sistemas de bancos de dados de hoje, explica: "Havia aquele cara, Ted Codd, que
usava um tipo de notação matemática estranha, mas ninguém a levava muito a sério". Então,
Ted Codd organizou um simpósio e Chamberlin ouviu como ele conseguiu resumir cinco pági-
nas de programas complicados em uma única linha. "E eu disse: Uau!", relembra Chamberlin.
O simpósio convenceu a IBM (Internacional Business Machines) a fundar o System R (Sistema R), um projeto de
pesquisa que construiu um protótipo de banco de dados relacional e que levaria à criação da SQL (Strutured Query
Language) e do DB2. Esta linguagem tornou-se um padrão na indústria para bancos de dados relacionais e, hoje
em dia, é um padrão ISO (International Organization for Standardization). Os primeiros protótipos foram utilizados
por muitas organizações, como o MIT Sloan School of Management (escola norte-americana conhecida na área
de negócios). Novas versões do sistema foram testadas com empresas de aviação para rastreamento do manufa-
turamento de estoque. A IBM, no entanto, manteve o System R em segundo plano por vários e decisivos anos. O
interesse da empresa voltava-se para o IMS, um sistema de banco de dados confiável, de alta tecnologia, que havia
surgido em 1968. Sem perceber o potencial de mercado daquela pesquisa, a IBM permitiu que sua equipe publicasse
seus trabalhos.
Entre os leitores estava Larry Ellison, que havia acabado de fundar uma pequena empresa. Recrutando programadores
do System R e da Universidade da Califórnia, Ellison conseguiu colocar no mercado, bem antes da IBM, o primeiro ban-
co de dados relacional com base em SQL, em 1979. Em 1983, a empresa laçou uma versão portátil do banco de dados,
tendo um faturamento bruto anual de US$ 5.000.000 e alterou seu nome para Oracle. Impedida pela concorrência, a
IBM finalmente lançou o SQL/DS (Structured Query Language/Data System), seu primeiro banco de dados relacional,
em 1980 (imagem disponível em: <http://www.answers.com/topic/edgar-f-codd>. Acesso em: 18 maio 2012.).
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
© U1 – Introdução aos Sistemas de Banco de Dados 23
4. INTRODUÇÃO À UNIDADE
Nesta unidade, você terá a oportunidade de estudar alguns conceitos de banco de dados,
bem como aprender a importância dos Sistemas Gerenciadores de Banco de Dados em sistemas
de informações. Para tanto, veja a definição a seguir:
Figura 1 Banco de Dados.
Banco de dados é um sistema de armazenamento de dados cujo objetivo é registrar e

guardar informações importantes que poderão ser acessadas quando necessário. Os bancos
de dados são amplamente usados, formando uma parte essencial de quase todas as empresas.
Veja alguns exemplos de onde são empregados os bancos de dados:
1) Instituições Financeiras (bancos): utilizam o banco de dados para o devido armaze-
namento de informações de seus clientes, suas respectivas contas, empréstimos e
transações bancárias.
2) Linhas Aéreas: seu banco de dados armazena reservas e informações de horários dos
voos. Sistemas computacionais de gerenciamento de linhas aéreas foram os primeiros
aplicativos a utilizar o banco de dados de maneira geograficamente distribuída.
3) Universidades: empregam o banco de dados para manipular informações dos alunos,
registros de cursos e notas.
4) Transações de Cartão de Crédito: constantemente utilizam bancos de dados para ge-
renciar compras com cartão de crédito e geração de faturas mensais.
5) Telecomunicação: o banco de dados é aplicado para manter registros de chamadas re-
alizadas, gerar cobranças mensais, gerenciar saldos de cartões telefônicos pré-pagos e
armazenar informações sobre status das redes de comunicações.
6) Finanças: na área financeira, o banco de dados é utilizado para armazenar informações
pertinentes aos valores mobiliários ou vendas e compras de instrumentos financeiros,
como ações e títulos. O banco de dados também é empregado no armazenamento
e gerenciamento de dados oriundos do mercado financeiro em tempo real, cuja fi-
nalidade é permitir aos clientes realizar negócios on-line e às empresas, transações
automatizadas.
7) Vendas: é imprescindível o uso de banco de dados para gerenciar e armazenar infor-
mações de cliente, produto e compra.
8) Indústria: utiliza o banco de dados para o gerenciamento da cadeia de suprimentos e
para o controle da produção de itens, estoques e pedidos nas fábricas.
9) Recursos Humanos: emprega banco de dados para armazenar e gerenciar informa-
ções referentes aos funcionários, salários, descontos em folha de pagamento, benefí-
cios, e também para a geração de contracheques.

Essa forma organizada de armazenamento permite a fácil manipulação dos dados, incluin-
do alterações, inserções, remoções, além das consultas.
É comum empregar os termos banco de dados e base de dados como sinônimos. De certa
forma é um erro, pois o gerenciamento de uma base de dados utiliza, normalmente, ferramen-
tas de apoio integradas à tomada de decisão organizacional; como exemplo, podem ser citados
o ERP (Enterprise Resource Planning) e o Data warehouse. Entretanto, o gerenciamento de um
banco de dados é o obtido por meio de sistemas de gerenciamento de bancos de dados.
Em geral, o gerenciamento eficiente de dados necessita do uso de um banco de dados
computacional (digital), que pode ser considerado como uma estrutura compartilhada e inte-
grada, a qual armazena um conjunto de:
• Dados brutos oriundos do usuário.
• Metadados, os quais permitem integrar e gerenciar os dados.
Os metadados fornecem uma descrição detalhada das características dos dados e do seu
conjunto de relacionamentos, responsáveis por conectar os dados encontrados no banco de
dados. Por exemplo, o componente de metadados armazena informações como o nome de cada
elemento de dados, seu respectivo tipo (numérico, data ou texto) armazenado, a possibilidade
ou não de deixar esse elemento vazio, dentre outras possibilidades. Desse modo, os metadados
fornecem informações que complementam e expandem o valor e a utilização dos dados, ou
seja, trazem uma representação mais completa dos dados no banco de dados.
A importância do banco de dados no cenário da Tecnologia da Informação (TI) aumentou
consideravelmente nos últimos anos, impulsionada pelo crescimento das aplicações web, das
implantações de ERP’s (Enterprise Resourcing Process), de BI (Business Intelligence) etc. Todas
essas tecnologias são dependentes do banco de dados por envolverem o armazenamento de
grandes volumes de dados, a recuperação de dados no menor tempo possível (principalmente
no comércio eletrônico), a segurança de acesso, o backup de dados em tempo real, dentre ou-
tras funções.
5. DADOS VERSUS INFORMAÇÕES

É importante que você entenda a diferença entre dados e informações. Os dados são con-
siderados fatos brutos, o que indica que os fatos ainda não foram processados para revelar seu
significado. Como exemplo, imagine que você queira saber o que os usuários de um laboratório
de informática pensam a respeito do serviço prestado. Normalmente, você começaria entrevis-
tando os usuários para avaliar o desempenho do laboratório. Você poderia usar um formulário
na web, o qual permitiria que os usuários respondessem às suas questões. Quando o formulário
estiver preenchido, os dados, nesse momento considerados como brutos, são armazenados em
um repositório de dados. Embora você já tenha os fatos em mãos, eles não possuem nenhuma
utilidade específica nesse formato. Portanto, é necessário transformar os dados brutos em da-
dos lapidados, o que permitirá a obtenção de respostas rápidas e objetivas das questões oriun-
das do formulário, como: "Qual é a composição da base de clientes de nosso laboratório?".
Para revelar seu significado, os dados brutos são processados de maneira apropriada, ge-
rando, assim, as informações. Esse processamento pode ser considerado simples (a organização
dos dados para extrair padrões, por exemplo) ou complexo (como a realização de estimativas,
empregando variáveis estatísticas). As informações necessitam conhecer seu contexto para re-
velar seu significado adequado. O simples fato de obtermos uma temperatura média de 95°, por
exemplo, pode ser considerado um dado específico sem significado algum, a menos que saiba-
mos seu contexto: encontra-se em graus Fahrenheit ou Celsius? Está vinculada à temperatura de
um hardware ou de um corpo humano?
Na maioria das vezes, as informações são pilares fundamentais para a tomada de decisões
nas empresas, sejam elas governamentais, de serviços ou filantrópicas. No exemplo anterior,
o resumo dos dados extraídos das questões referentes a cada formulário de entrevista pode
demonstrar os pontos fortes e fracos do laboratório de informática, auxiliando, dessa forma, na
tomada de decisões confiáveis para melhor atender às necessidades de seus clientes.
De acordo com as características e a aplicabilidade dos dados armazenados, os bancos são
classificados de diferentes maneiras: podem se basear no número de usuários, na localização
(ou localizações) e no tipo e extensão do uso esperado.
Veja a classificação dos bancos de dados por número de usuários:
1) Banco de dados monousuário (de um único usuário): suporta apenas um usuário por
vez. Por exemplo, se o usuário Pedro estiver utilizando o banco de dados, os usuários
Regina e Douglas precisam esperar o usuário Pedro finalizar sua consulta.
2) Banco de dados multiusuário: dá suporte a diversos usuários simultaneamente. Por
exemplo, os usuários Pedro, Regina e Douglas poderão utilizar o banco de dados ao
mesmo tempo.
Outra característica importante dos bancos de dados pode ser estabelecida levando em
consideração sua localização. Observe:
1) Banco de dados centralizado: estabelece suporte a dados centralizados em um único
local.
2) Banco de dados distribuído: suporta dados distribuídos por vários locais, normalmen-
te, geograficamente distintos.
Atualmente, a maneira mais usual de classificar os bancos de dados baseia-se no modo
como estes serão utilizados e na sensibilidade ao tempo das informações nele coletadas. Pode-
mos detalhar essa classificação como:
1) Bancos de dados operacionais: projetados especialmente para suportar operações
diárias de uma empresa. Também podem ser referenciados como bancos de dados
transacionais ou de produção.
2) Data Warehouse (armazém de dados): tem a finalidade de armazenar os dados uti-
lizados para a geração de informações necessárias à tomada de decisões táticas e
estratégicas. Essas decisões exigem que os dados sejam "lapidados" (manipulação de
dados), a fim de extrair informações úteis para a formulação de decisões, previsões
de vendas, posicionamento no mercado, dentre outros. Sua estrutura difere-se muito
de um banco de dados operacional ou transacional, promovendo facilitadores para a
recuperação desses dados.
3) Bancos de dados temporais: são aqueles que permitem ao usuário a consulta dos
estados atuais e passados do banco de dados, pois armazenam históricos das altera-
ções. Veja alguns exemplos de aplicações, em que o controle e acesso a informações
temporais são fundamentais: área médica (evolução do paciente), área empresarial
(aplicações financeiras, controle de produção, gerenciamento de vendas, gestão de
pessoas), controle acadêmico, sistemas de informações geográficas, sistemas de re-
servas, entre outros.
4) Bancos de dados espaciais: são aqueles que permitem consultas a objetos localiza-
dos em um espaço multidimensional. É o caso dos bancos de dados geográficos, que
armazenam informações sobre mapas para localização de rios, cidades, estados, es-
tradas, entre outros.

5) Bancos de dados meteorológicos: são aqueles que armazenam informações sobre o

tempo.
6) Bancos de dados de multimídias: são aqueles que armazenam os dados sob a forma
de imagens, vídeos, músicas, textos falados ou escritos, entre outros.
7) Bancos de dados especialistas: também conhecidos como sistemas baseados em co-
nhecimento, são aqueles que, por meio de técnicas aplicadas na área da Inteligência
Artificial, incorporam raciocínio e inferência (capacidade de dedução).
Os bancos de dados também podem ser classificados de acordo como os dados são estru-
turados. Dados não estruturados são aqueles que existem em seu estado original (estado bruto),
no formato em que foram coletados. Entretanto, esse formato não permite o processamento
adequado para produzir informações. Já os dados estruturados são o resultado da obtenção de
dados não estruturados, como também sua formatação, facilitando, assim, o armazenamento, a
manipulação e a geração de informações. O formato (estrutura) é utilizado baseando-se no tipo
de processamento que desejamos realizar nos dados. Alguns dados podem não estar prontos
(não estruturados) para determinados tipos de processamento, todavia, podem estar prontos
(estruturados) para outros tipos. Podemos utilizar, como exemplo, o valor de um dado específi-
co, como o valor 140070131, o qual pode referir-se a um CEP, um valor de vendas ou um código
de um determinado produto. Por um lado, caso represente um CEP ou um código de produto e
for armazenado como texto, não será permitido a realização de cálculos matemáticos com ele.
Por outro lado, se o mesmo valor representar uma transação de vendas, torna-se necessário
formatá-lo como numérico.
Contudo, a maioria dos dados encontrados são classificados como semiestruturados, que
são aqueles parcialmente processados.
Recentemente, as necessidades de armazenamento e gerenciamento de dados não es-
truturados e semiestruturados estão sendo atendidas pela nova geração de bancos de dados,
nomeados de XML. A XML (sigla em inglês para Extensible Markup Language) é considerada
uma linguagem especial utilizada para representar e manipular elementos de dados em formato
textual. Os bancos de dados em XML suportam o armazenamento e gerenciamento de dados
semiestruturados em XML. A Tabela 1 realiza a comparação dos Sistemas de Gerenciamento de
Bancos de Dados mais conhecidos no mercado.
Tabela 1 Tipos de bancos de dados.

NÚMERO DE USUÁRIOS LOCALIZAÇÃO DE DADOS UTILIZAÇÃO DE DADOS
PRODUTO Data XXML
Monousuário Multiusuário Centralizado Distribuído Operacional
Warehouse
PostgreSQL X X X X X X X*
MS SQL Server X** X X X X X X
DB2 X** X X X X X X
MySQL X X X X X X X*
Oracle (SGBDR) X** X X X X X X
* Promove suporte apenas a funções de XML. Os dados em XML são armazenados em grandes objetos de texto.
** O fornecedor oferece versão específica do SGBD.
Ao analisarmos a Tabela 1, podemos perceber as especificidades que cada produto apre-

senta em relação à classificação dos bancos de dados.
6. SISTEMAS DE ARQUIVOS VERSUS SGBDS

Você já ouviu falar em FAT, FAT 32, NTFS? E SQL Server, Oracle e MySQL?
Todas essas siglas têm um objetivo em comum: organizar e armazenar dados em sistemas
computacionais. Elas fazem parte de dois sistemas para controle de informação, o Sistema de
Arquivos e o Sistema Gerenciador de Banco de Dados (SGBD).
Sistema de arquivos é o método de organizar e armazenar informações seguindo uma es-
trutura lógica para alocação física dos arquivos em dispositivos de armazenamento, tais como:
disco rígido ou CD-ROM. Em outras palavras, o sistema de arquivos é a estrutura que indica como
os arquivos devem ser gravados e guardados em algum sistema de armazenamento. A maioria
dos sistemas de arquivos utiliza recursos de armazenamento de dados que se apresentam como
um conjunto de blocos com tamanho fixo, denominado de setores, cada qual com 512 bytes.
O controle de acesso aos discos de armazenamento é realizado por sistemas operacionais
como MS-DOS, Windows, Linux ou Unix. O software dos sistemas de arquivos é responsável por
organizar esses setores em arquivos e diretórios, além de manter a informação sobre a qual se-
tor pertence um arquivo e qual setor está disponível.
Existem sistemas de arquivos que você provavelmente utiliza no seu dia a dia, conhecidos
como FAT (File Allocation Table), FAT32 e NTFS (New Technology File System), presentes no sis-
tema operacional Windows. A diferença entre eles está relacionada às limitações da tecnologia
que foram superadas e à necessidade de melhorias, como segurança e capacidade de arma-
zenamento. Devido à confiabilidade presente no sistema de arquivos, o FAT e o FAT32 foram
incorporados ao sistema de arquivos NTFS.
Os sistemas de arquivos funcionam por meio de uma espécie de tabela, que contém in-
dicações da localização das informações de cada arquivo. Quando um arquivo é salvo em um
disquete, por exemplo, o FAT divide a área do disco em pequenos blocos. Assim, um arquivo
ocupa vários desses blocos, mas eles não precisam estar em uma sequência. Os blocos de deter-
minados arquivos podem estar em várias posições diferentes. Por isso, existe a necessidade de
uma tabela para indicar cada bloco.
Observe, na Figura 2, a representação de um sistema de arquivos. É importante lembrar
que aplicativos são programas computacionais desenvolvidos que utilizam uma linguagem de
programação com a finalidade de solucionar problemas e auxiliar nas atividades computacio-
nais.

Figura 2 Sistema de Arquivos.
Arquitetura de sistemas é a forma como o sistema terá os seus componentes organizados

e estruturados para realizar a tarefa determinada. A arquitetura contém um plano e uma lógica,
em que o sistema desenvolvido executará suas atividades.
O sistema de arquivos foi uma das primeiras arquiteturas de sistemas para armazenamen-
to e manipulação de dados e geração de informação, e, ao longo do tempo, sofreu alterações e
foi adaptado conforme a evolução tecnológica. No entanto, alguns problemas ainda são encon-
trados, tais como:
1) A manutenção: ela é prejudicada, pois a estrutura de arquivos é definida e padroniza-
da no próprio código do aplicativo.
2) O compartilhamento de um arquivo por vários programas: apresenta dificuldades
para gerenciar o acesso a esses arquivos e seu controle.
3) As incompatibilidades nos aplicativos: o desenvolvimento de arquivos e programas
de um mesmo sistema operacional, ao ser realizado isoladamente por diferentes pro-
gramadores, e até mesmo em linguagens diferentes, causa tais incompatibilidades,
prejudicando as funcionalidades do sistema.
4) A inconsistência (aplicativos com informações incorretas), o isolamento de dados (for-
matos distintos), a redundância (dados repetidos) e os problemas com segurança (fá-
cil acesso aos registros do sistema).
5) A falta de gerenciamento para acessos concorrentes (vários usuários acessando a
mesma informação) aos dados e recuperação de dados.
Observe, a seguir, um exemplo que engloba a inconsistência e a falta de gerenciamento
de acesso. Suponha que dois alunos estejam consultando o acervo de uma biblioteca digital à
procura do mesmo livro. A biblioteca possui um único exemplar disponível para empréstimo, e
essa informação é apresentada para os dois alunos que consultam o acervo. Ambos realizam a
consulta e fazem a reserva no mesmo instante. Isso causará um problema no sistema, pois have-
rá inconsistência de dados. A inconsistência e a falta do gerenciamento da informação geraram
uma falha: o sistema não foi capaz de bloquear a reserva de um dos estudantes e dizer que o
livro já havia sido reservado para o outro.
Você percebe a necessidade das informações serem atualizadas em tempo real? Caso con-
trário, o que aconteceria com os sistemas bancários, os sistemas que realizam vendas pela inter-
net ou reservas de voos aéreos?
Com as exigências e necessidades de novos conceitos e estruturas nos sistemas de arqui-
vos, percebeu-se um aumento significativo nos custos de equipamentos, manutenção e tempo
de trabalho para atender todas essas novas demandas. Dessa forma, os Sistemas de Geren-
ciamento de Banco de Dados (SGBD) surgiram como uma evolução dos Sistemas de Arquivos,
criando novas estruturas de dados com o objetivo de gerenciar todo o armazenamento de in-
formações.
O SGBD é uma coleção de programas que permite ao usuário definir, construir e manipular
bases de dados para as mais diversas finalidades. Os programas ou softwares SGBDs mais co-
nhecidos são Microsoft Access, MySQL, Oracle, FireBird, SQL Server e PostgreSQL.
No Sistema de Gerenciamento de Banco de Dados (SGBD), o acesso aos dados e seu geren-
ciamento são realizados pelo próprio sistema, o qual funciona como uma interface (ponto que
delimita e estabelece a relação entre dois sistemas independentes) entre o banco de dados e os
programas aplicativos, isto é, o SGDB está localizado entre o banco de dados físico e os usuários.
Um Sistema Gerenciador de Banco de Dados é responsável por receber as requisições
provenientes de diversas aplicações e realizar a tradução, quebrando a complexidade das solici-
tações e permitindo o atendimento a essas requisições adequadamente. O SGBD consegue ocul-
tar dos usuários e aplicativos grande parte da complexidade existente em um banco de dados.
Normalmente, os aplicativos computacionais que interagem com os bancos de dados por meio
de um Sistema Gerenciador de Banco de Dados podem ser implementados pelos programado-
res utilizando diversas linguagens de programação, como por exemplo, o Visual Basic, Dot Net,
Java, PHP ou C++. Além do uso de linguagens de programação específicas, existe a possibilidade
de desenvolver aplicativos baseando-se exclusivamente em ferramentas proprietárias dos Siste-
mas Gerenciadores de Banco de Dados, como por exemplo, o Forms e Reports da Oracle.
Como vimos anteriormente, os dados constituem um material bruto fundamental a partir
do qual as informações são obtidas, e requerem um excelente método para gerenciá-los. Você
descobrirá que o SGBD torna o gerenciamento de dados mais eficientes e eficazes. Como exem-
plo, mencionamos suas diversas vantagens na utilização em aplicações computacionais. O SGBD:
1) Permite o compartilhamento dos dados para diversas aplicações e usuários.
2) Integra as visões dos dados dos diferentes usuários em um único repositório de dados.
3) Fornece modelos adequados para melhor aplicar as políticas de privacidade e segu-
rança de dados.
4) Reduz a inconsistência dos dados, que ocorre quando diferentes versões dos mesmos
dados aparecem em locais distintos. Por exemplo, quando o departamento de ma-
rketing de uma determinada empresa armazena o nome de uma funcionária como
"Gisele Ap. da Silva" e o departamento de recursos humanos, por sua vez, armazena o
nome da mesma funcionária como "Gisele A. Silva".
5) Dados bem gerenciados e com acesso aprimorado permitem a geração de informa-
ções de melhor qualidade, que, por sua vez, auxiliam na tomada de decisões.
As vantagens da utilização de um SGBD não se limitam aos itens listados. Certamente,
você descobrirá inúmeras utilidades ao conhecer os detalhes dos bancos de dados e seu projeto
adequado.
O SGBD apresenta uma visualização única e integrada ao usuário (ou aplicativos), confor-
me pode ser visualizado na Figura 3.
Figura 3 Sistema de Banco de Dados.
O SGBD solucionou problemas dos sistemas de arquivos, tais como: integração de dados
(mesmo local), dados duplicados, independência de dados e aplicativos e representação das
perspectivas do usuário.
Desenvolvedores, administradores e usuários que trabalham diretamente com SGBDs de-
vem ter conhecimento e domínio dos recursos para usufruir de todas as vantagens que o siste-
ma proporciona, como:
1) Rapidez no acesso às informações presentes no banco de dados.
2) Redução de problemas de integridade e redundância.
3) Diminuição do esforço humano no desenvolvimento.
4) Utilização dos dados e controle integrado de informações distribuídas fisicamente.
Desconhecer o funcionamento do SGBD pode acarretar o mau desenvolvimento e afetar a
segurança de acesso às informações.
Uma das comparações realizadas entre o sistema de arquivos e o SGBD está relacionada
ao desempenho. O sistema de arquivos é programado para uma aplicação específica, o que gera
um bom desempenho. Já o SGBD é programado para aplicações mais genéricas, podendo aten-
der a aplicações diferentes.
Em outras palavras, podemos dizer que os SGBDs vieram para eliminar todo o trabalho
realizado anteriormente por um programador de aplicação, responsável pelo controle do aces-
so, da integridade e da redundância dos dados; contudo, ainda há alguns itens que são melhor
atendidos pelos sistemas de arquivos.
7. DADOS EM SGBDS: DESCRIÇÃO E ARMAZENAMENTO

Os dados são informações que podem ser gravadas e que possuem um significado implíci-
to. O banco de dados (BD) é uma coleção de dados relacionados que:
• Representa aspectos do mundo real (minimundo ou universo de discurso). Portanto, as
mudanças que ocorrem no mundo real devem ser refletidas no BD.
• Descreve uma coleção lógica e coerente de dados com algum significado inerente. Uma
organização randômica, ou seja, aleatória, de dados não pode ser considerada um BD.
• Constrói em atendimento a uma proposta específica.
Um Sistema Gerenciador de Banco de Dados (SGBD) é uma coleção de programas que per-
mite aos usuários criarem e manterem um banco de dados. Ele foi definido para ser um sistema
de software de propósito geral que facilita os processos de definição, construção, manipulação
e compartilhamento de bancos de dados entre vários usuários e aplicações.
São características oferecidas pelos SGBDs:
1) Rapidez: agilidade na execução das consultas on-line.
2) Disponibilidade total: significa que todas as vezes que uma informação for solicitada,
ela deve estar disponível e atualizada.
3) Flexibilidade: facilidade na implementação de mudanças.
4) Integridade: garantia da consistência dos dados quando atualizações são efetuadas
no banco.
Para atingir os objetivos propostos pelo SGBD, você verá que é necessário ter uma estru-
tura com níveis bem definidos e utilizar um modelo de dados adequado para descrever o banco
de dados.
Níveis de Abstração de Dados

Normalmente, quando constituímos um projeto de banco de dados, iniciamos a partir de
uma visão abstrata do ambiente como um todo, acrescentando detalhes à medida que o projeto
evolui para a sua implementação. Utilizar níveis de abstração de dados pode ser extremamente
útil no que diz respeito à integração de visões múltiplas de dados, como podemos presenciar em
distintos níveis de uma empresa.
O Comitê de Planejamento e Exigência de Padrões (SPARC) do Instituto Nacional America-
no de Padrões (ANSI) definiu, no início da década de 1970, uma estrutura de modelagem com
base em níveis de abstração de dados. A arquitetura ANSI/SPARC define três níveis de abstração
de dados: externo, conceitual e interno.
Modelo Externo
Esse modelo é considerado a perspectiva dos usuários finais do ambiente de dados. Usu-
ários finais é o termo dado às pessoas que fazem uso de aplicativos para manipular os dados,
gerando, assim, as informações necessárias para o cenário empresarial.
Normalmente, as empresas são segmentadas em diversas unidades comerciais, como:
vendas, finanças e marketing, em que cada unidade pode estar sujeita a restrições e exigências
específicas. Dessa maneira, os usuários finais podem visualizar apenas seus subconjuntos de
dados específicos, separados das outras unidades da empresa.

Registro de alunos
Um aluno pode pegar até seis

turmar por registro.
Uma turma limita-se a

35 alunos.
Figura 4 Modelos externos de uma instituição acadêmica Sistema de Banco

de Dados.
Na Figura 4, imagine os esquemas externos de duas unidades comerciais corresponden-

tes a uma instituição acadêmica: registro de alunos e agendamento de turmas. Cada esquema
externo inclui as entidades, relacionamentos e restrições determinadas pela unidade comercial
(departamento). Observamos que, embora as visões das aplicações sejam isoladas, cada visão
compartilha sua unidade com a outra (os esquemas externos pertinentes ao registro de alunos
e o agendamento de turmas compartilham as entidades TURMA e DISCIPLINA).
Em detalhes, podemos descrever as entidades-relacionamentos representados pela Figu-
ra 4:
1) Um PROFESSOR ensina muitas TURMAs, porém, cada TURMA é ensinada por apenas
um PROFESSOR. Ou seja, existe um relacionamento 1:M entre PROFESSOR e TURMA.
2) Uma TURMA pode receber a MATRÍCULA de diversos alunos, e para cada aluno é per-
mitida a MATRÍCULA em várias TURMAs, formando, assim, um relacionamento M:N
entre ALUNO e TURMA.
3) Para cada DISCIPLINA é permitida a geração de muitas TURMAs, mas cada TURMA
se refere apenas a uma DISCIPLINA, conforme pode ser observado na cardinalidade
mínima e máxima.
4) Por fim, uma TURMA normalmente necessita de uma SALA, mas uma SALA pode ser
reservada para várias TURMAs. Ou seja, cada sala de aula pode ser utilizada por diver-
sas turmas, uma em cada horário, por exemplo. Dessa forma, podemos identificar a
existência de um relacionamento 1:M entre SALA e TURMA.
Modelo Conceitual
Após a identificação das visões externas, utilizamos o modelo conceitual, o qual é repre-
sentado graficamente pelo diagrama de entidade e relacionamento (DER) que, na prática, cons-
titui a planta básica do banco de dados. O modelo conceitual tem como objetivo realizar a inte-
gração de todas essas visões externas (entidades, relacionamentos e restrições) em uma visão
global de todos os dados da empresa.
O ER (entidade-relacionamento) é o modelo conceitual mais utilizado. Dentre as vanta-
gens apresentadas pelo modelo conceitual, podemos destacar:
• Fornecimento de uma visão macroscópica de fácil entendimento sobre o ambiente de
dados.
• Independência de software: o modelo não depende da tecnologia do Sistema de Ge-
renciamento de Banco de Dados (SGBD) utilizado em sua implementação, ou seja, as
alterações provenientes do software não refletirão sobre o projeto de banco de dados
no nível conceitual.
• Independência de hardware: o modelo não depende do hardware utilizado em sua
implementação, ou seja, as alterações provenientes do hardware não refletirão sobre
o projeto de banco de dados no nível conceitual.
Modelo Interno
Nessa fase, normalmente já definimos qual tecnologia de Sistema de Gerenciamento de
Banco de Dados (SGBD) será utilizada. O modelo interno realiza o mapeamento do modelo con-
ceitual para o SGBD específico.
Quando utilizamos o modelo relacional (o qual será detalhado adiante), escolhemos um
banco de dados que suporta esse tipo para implementar o modelo interno, o qual se resume no
mapeamento do modelo conceitual para as tabelas do modelo relacional. O esquema interno
é constituído pela SQL (linguagem padrão) quando selecionamos o banco de dados relacional.
Como exemplo, a Figura 5 apresenta o modelo interno implementado, criando-se as tabelas
PROFESSOR, DISCIPLINA, TURMA, ALUNO, MATRÍCULA e SALA.
Devido à dependência do modelo interno a um software de SGBD específico, dizemos que
ele é dependente de software. Qualquer alteração realizada na tecnologia do SGBD exigirá que
o modelo interno sofra algum tipo de alteração a fim de se adequar às novas características e
exigências de implementação do modelo de banco de dados. Em alguns casos, é possível alte-
rarmos o modelo interno sem interferir no modelo conceitual, obtendo, assim, a independência
lógica. Entretanto, o modelo interno possui independência de hardware, ou seja, esse modelo
não sofrerá nenhum tipo de alteração/modificação pela escolha do computador em que o sof-
tware (SGBD) será instalado.

Create Table PROFESSOR (

PROF_ID NUMBER PRIMARY KEY,
PROF_SOBRENOME CHAR(15),
PROF_INICIAL CHAR(1),
PROF_NOME CHAR(15));
Create Table TURMA (

TURMA_ID NUMBER PRIMARY KEY,
DIS_ID CHAR(8) REFERENCES DISCIPLINA,
PROF_ID NUMBER REFERENCES PROFESSOR,
PROF_NOME CHAR(8) REFERENCES SALA);
Create Table SALA (

SALA_ID CHAR(8) PRIMARY KEY,
SALA_TIPO CHAR(3));
Create Table DISCIPLINA (

DIS_ID CHAR(8) PRIMARY KEY,
DIS_NOME CHAR(25),
DIS_CREDITO NUMBER);
Figura 5 Modelo Interno (Instituição Acadêmica).
Modelo Físico
Este modelo trabalha nos níveis mais baixos de abstração, ou seja, descreve a maneira
como os dados são gravados em meios de armazenamento, como discos e fitas magnéticas. O
modelo físico carece da definição dos dispositivos de armazenamento físico, como também seus
métodos de acesso a esse meio. Consequentemente, podemos dizer que esse modelo é depen-
dente tanto do software (SGBD) como do hardware.
Mesmo que no modelo relacional o projetista do banco de dados não precise se preocu-
par com as características inerentes ao armazenamento físico dos dados, a implementação de
um modelo relacional poderá exigir sintonização (tuning) refinada no nível físico para otimizar
o desempenho.
Sabemos que o modelo físico depende da tecnologia do SGBD, dos mecanismos de acesso
aos arquivos e dos tipos de dispositivos utilizados para efetuar o armazenamento. Eventual-
mente, quando é possível realizar qualquer tipo de alteração no modelo físico sem influenciar o
modelo interno, ocorre o que chamamos de independência física.
Modelo de Dados
Um modelo de dados é uma representação relativamente simples, em geral gráfica, de es-
truturas mais complexas de dados reais. Normalmente, o modelo é uma abstração de um objeto
ou até mesmo um evento real com um maior grau de complexidade. Tem como função principal
auxiliar na compreensão das regras de negócios complexos existentes em um ambiente real. Em
um cenário de bancos de dados, um modelo representa estruturas de dados e suas característi-

cas, como: relações, restrições, transformações, dentre outros elementos que possuem o mesmo
objetivo, ou seja, dar suporte ao problema específico de um determinado domínio de negócios.
Habitualmente, os projetistas de bancos de dados confiam no bom senso na hora de de-
senvolver bons modelos. Por exemplo, se os estudantes de uma turma têm de criar, individual-
mente, um modelo de dados para uma locadora de filmes, é muito provável que cada um apre-
sente um modelo diferente. Qual estaria correto? A resposta é simples: "aquele que atender a
todas as necessidades do usuário final", podendo haver mais de uma solução correta.
Um modelo de dados bem desenvolvido pode inclusive promover uma compreensão apri-
morada da organização para a qual o banco está sendo desenvolvido. Em resumo, os modelos
de dados são uma ferramenta de comunicação. Esse aspecto importante da modelagem foi
sintetizado claramente por um cliente, cuja reação foi a seguinte: "Eu criei esta empresa, traba-
lhei nela por anos e esta é a primeira vez em que eu realmente entendi como todas as partes se
encaixam na prática".
Da mesma forma que a planta de uma casa é uma abstração, o modelo de dados é, de
modo similar, uma abstração; não é possível obter os dados necessários a partir do modelo. Se
dificilmente se construirá uma boa casa sem uma planta, é também improvável criar um bom
banco de dados sem a prévia criação de um modelo de dados adequado.
Objetos Básicos
Os blocos básicos de construção de todos os modelos de dados são as entidades, os atri-
butos, os relacionamentos e as restrições.
Uma entidade é algo (pessoa, local, objeto ou evento) sobre o qual são coletados e arma-
zenados dados. Ela representa um tipo particular de objeto no mundo real. Por isso, as entidades
são distinguíveis, ou seja, cada ocorrência de entidade é única e distinta. Por exemplo, uma enti-
dade Cliente teria muitas ocorrências de clientes distinguíveis, como Manoel Ribeiro, Pedro José
da Silva, Dinorá Fernandes Junqueira etc. As entidades podem ser objetos físicos, como clientes
e produtos, mas também podem ser abstrações, como rotas de voo ou apresentações musicais.
Um atributo é considerado uma característica de uma entidade. Por exemplo, uma entida-
de Cliente seria caracterizada pelos atributos nome, sobrenome, telefone, endereço e limite de
crédito. Os atributos são equivalentes aos campos nos sistemas de arquivos.
Um relacionamento descreve uma associação (conectividade) entre entidades (uma ou
n). Por exemplo, um relacionamento entre clientes e corretores pode ser descrito da seguinte
maneira: um corretor pode atender muitos clientes, mas cada cliente pode ser atendido apenas
por um corretor. Os modelos de dados utilizam três tipos de relacionamentos: um para muitos
(1:M ou 1..*), muitos para muitos (M:N ou *..*) e um para um (1:1 ou 1..1).
Veja, a seguir, exemplos que ilustram as distinções entre os três tipos de relacionamentos
permitidos.
• Relacionamento um para muitos (1:M ou 1..*): um pintor faz várias pinturas, mas cada
uma é criada por apenas um artista; o pintor (uma entidade) relaciona-se com as pin-
turas (várias entidades). Portanto, podemos definir o relacionamento PINTOR pinta
PINTURA como sendo 1:M. De modo similar, um cliente (entidade) pode gerar muitas
faturas (várias entidades), mas cada fatura é gerada apenas por um cliente. O relacio-
namento CLIENTE gera FATURA também seria identificado como 1:M.

• Relacionamento muitos para muitos (M:N ou *..*): um funcionário pode aprender

várias habilidades profissionais e cada habilidade profissional pode ser aprendida por
vários funcionários. Esse tipo nos permite identificar o relacionamento FUNCIONÁRIO
aprende HABILIDADE como M:N. De modo similar, um aluno pode frequentar várias
turmas e cada turma pode ser frequentada por vários alunos, conferindo-se, assim, a
identificação M:N ao relacionamento expresso por ALUNO frequenta TURMA.
• Relacionamento um para um (1:1 ou 1..1): a estrutura de gerenciamento de uma empre-
sa de varejo pode exigir que cada uma de suas lojas seja gerenciada por um único funcio-
nário. Por sua vez, cada gerente de loja, que é um funcionário, gerencia apenas uma loja.
Portanto, o relacionamento FUNCIONÁRIO gerencia LOJA é identificado como 1:1.
A discussão precedente identificou cada relacionamento em duas direções, ou seja, os
relacionamentos são bidirecionais (grau dois ou binário). Veja:
• Um CLIENTE pode gerar diversas faturas.
• Cada uma das várias FATURAS é gerada apenas por um CLIENTE.
A restrição é uma limitação imposta aos dados. As restrições são importantes, pois aju-
dam a assegurar a integridade dos dados. Elas normalmente são expressas na forma de regras.
Por exemplo:
• O salário de um funcionário possui valores entre R$ 1.000,00 e R$ 5.000,00.
• A média de nota de um aluno deve estar entre o intervalo 0,0 e 10,0.
• Cada turma deve ter um e apenas um professor.
Como é possível identificar, de maneira adequada, as entidades, os atributos, os relacio-
namentos e as restrições? A primeira etapa é identificar as regras de negócio para o domínio do
problema que está sendo modelado.
Uma regra de negócio é uma descrição breve, precisa e sem ambiguidade de uma política,
procedimento ou princípio em uma determinada organização. As regras de negócio se aplicam
a qualquer tipo de organização, seja ela grande ou pequena – uma empresa, uma instituição
pública, um grupo religioso ou um laboratório de pesquisa – que armazene e manipule dados
para gerar informações importantes na tomada de decisões.
Regras de negócio adequadas são utilizadas para definir entidades, atributos, relaciona-
mentos e restrições. Sempre que você vir uma descrição de relacionamento como "um corretor
pode atender muitos clientes, mas cada cliente pode ser atendido por apenas um corretor",
você verá as regras de negócio em ação.
Essas regras descrevem, em linguagem simples, as principais características dos dados
conforme vistos pela empresa. Os seguintes itens são exemplos de regras de negócio:
• Um cliente pode gerar muitas faturas.
• Uma fatura é gerada por apenas um cliente.
• Uma seção de treinamento não pode ser agendada para menos de 10 funcionários ou
mais de 30.
Observe que essas regras de negócio estabelecem entidades, relacionamentos e restri-
ções. Por exemplo, as duas primeiras regras estabelecem duas entidades (CLIENTE e FATURA) e
um relacionamento 1:M entre elas. A terceira regra de negócio estabelece uma restrição (não
menos de 10 pessoas e não mais de 30), duas entidades (FUNCIONÁRIO e TREINAMENTO) e um
relacionamento entre FUNCIONÁRIO e TREINAMENTO.
Convertendo Regras de Negócio em Modelos de Dados

As regras de negócio constituem um cenário adequado para a identificação correta dos
objetos do modelo de dados, como suas entidades, atributos, relacionamentos e restrições.
Em um cenário real, os nomes são utilizados para identificar objetos. Se o ambiente de negócio
desejar rastrear os objetos, haverá regras específicas para eles. Geralmente, um substantivo em
uma regra de negócio será traduzido como entidade no modelo de dados, e um verbo que asso-
cie substantivos será traduzido como um relacionamento entre entidades. Por exemplo, a regra
de negócio "um CLIENTE pode GERAR várias FATURAS" contém dois substantivos (CLIENTES e
FATURAS) e um verbo (GERAR) que associa os substantivos. Conclui-se a partir dessa regra que:
• CLIENTE e FATURA são objetos de interesse para o ambiente e devem ser representa-
dos por suas respectivas entidades.
• Há um relacionamento GERAR entre as entidades CLIENTE e FATURA.
Para identificar adequadamente o tipo, deve-se considerar que os relacionamento são
bidirecionais, ou seja, valem em ambos os sentidos. Por exemplo, a regra "um CLIENTE pode
GERAR várias FATURAS" é complementada pela regra "uma FATURA é gerada por apenas um
CLIENTE". Nesse caso, o relacionamento é um para muitos (1:M). O CLIENTE é o lado um e a
FATURA, o lado muitos. Normalmente, para fazer essa identificação do tipo de relacionamento,
devemos fazer duas perguntas:
• Quantas instâncias de B são relacionadas a uma instância de A?
• Quantas instâncias de A são relacionadas a uma instância de B?
É possível avaliar o relacionamento entre ALUNO e DISCIPLINA fazendo as seguintes per-
guntas:
• Em quantas disciplinas um aluno pode se matricular? Resposta: várias disciplinas.
• Quantos alunos podem se matricular em uma disciplina? Resposta: vários alunos.
Portanto, o relacionamento entre ALUNO e DISCIPLINA é de muitos para muitos (M:N).
A busca por um melhor gerenciamento de dados gerou vários modelos que tentaram re-
solver as falhas fundamentais do sistema de arquivos. Na Tabela 2 podemos ter uma visão geral
dos principais modelos de dados, em ordem cronológica.
Tabela 2 Detalhes sobre a evolução dos principais modelos de dados.

geração Época modelo exemplos comentários
Primeira Década de 1960 Sistema de VMS/VSAM Utilizado pela IBM nos sistemas de
a 1970 arquivos mainframe.
Sem utilizar relacionamentos, gerenciava os

registros.
Segunda Década de 1970 Modelo IMS Caracterizavam os primeiros bancos de dados.
de dados
hierárquico e em ADABAS
rede
IDS-II
Terceira Década de 1970 Modelo de DB2 Conceitos básicos simples e objetivos.
até o presente dados relacional
Oracle Modelagem entidade-relacionamento (ER) e
suporte à modelagem relacional de dados.
MS SQL Server
MySQL
PostgreSQL

geração Época modelo exemplos comentários

Quarta Década de 1980 Orientado Versant Promove suporte a dados complexos.
até o presente a objetos
relacionais Caché Produtos relacionais estendidos com suporte
estendidos a warehouse de dados e objetos.
FastObjects.Net
Propagação de banco de dados na web.
Objectivity/DB
DB/2 UDB
Próxima geração Do presente ao XML dbXML Promove organização e gerenciamento de
futuro dados não estruturados.
Tamino
Modelos relacionais e de objetos adicionam
DB2 UDB suporte a documentos em XML.
Oracle 10g
MS SQL Server
PostgreSQL
Modelo Hierárquico
Desenvolvido na década de 1960, o modelo hierárquico tinha por objetivo gerenciar gran-
des quantidades de dados provenientes de projetos complexos. Podemos mencionar como
exemplo o foguete Apollo, que aterrissou na Lua em 1969. Sua estrutura lógica é representada
por uma estrutura semelhante à de uma árvore, visualizada de cima para baixo, onde identifi-
camos seus níveis ou segmentos. Um segmento é semelhante ao tipo de registro em um siste-
ma de arquivos qualquer. Internamente, por hierarquia, a camada considerada superior (raiz) é
identificada como pai do segmento imediatamente abaixo dela. Na Figura 6 podemos visualizar
o segmento considerado Raiz como o pai dos segmentos do Nível 1 que, por sua vez, são pais
dos segmentos do Nível 2, e assim sucessivamente. Os segmentos encontrados abaixo de outros
segmentos são identificados como filhos. Resumidamente, podemos considerar que o modelo
hierárquico representa um conjunto de relacionamentos um para muitos (1:M) entre um pai e
seus filhos, ou seja, cada pai pode ter muitos filhos, entretanto, cada filho possui apenas um
pai.
Montagem
Segmento Raiz Final
Segmento de Nível 1
Componente A Componente B Componente C
(Filhos da Raiz)
Montagem A Montagem B Montagem C
(Filhos da Nível 1)
Parte A Parte B Parte C Parte D Parte E
(Filhos da Nível 2)
Figura 6 Estrutura Hierárquica.
O banco de dados hierárquico tornou-se referência na década de 1970, somando uma

série de vantagens em relação aos sistemas de arquivo. Consequentemente, gerou uma base
significante para o desenvolvimento de aplicações comerciais. Porém, o modelo hierárquico
apresentava diversas limitações, entre elas a dificuldade de implementação e gerenciamento,
a falta de independência estrutural e o fato de a maioria dos relacionamentos de dados mais

comuns se adaptarem à forma 1:M.
Modelo em Rede
O modelo em rede foi criado para representar, exclusivamente, relacionamentos de dados
complexos com maior eficiência (em comparação ao modelo hierárquico), otimizando o desem-
penho dos bancos de dados e determinando um padrão para os mesmos.
No modelo em rede, em geral, o usuário visualiza o banco de dados em rede como uma
coleção de registros em relacionamentos 1:M. Ao contrário do modelo hierárquico, esse modelo
permite que um registro tenha mais de um pai. Um exemplo desse relacionamento é apresen-
tado na Figura 7.
Figura 7 Modelo de dados de rede.
A Figura 7 ilustra um modelo de dados em rede de uma empresa de vendas qualquer. Nes-
se modelo podemos identificar os tipos de registros: CLIENTE, REPCOMERCIAL, FATURA, FAT_LI-
NHA, PRODUTO e PAGAMENTO. Observe que a FATURA é propriedade tanto do REPCOMERCIAL
como do CLIENTE. De maneira similar, FAT_LINHA possui dois proprietários, PRODUTO e FATURA.
A ausência de um recurso de consulta ad hoc não permitia aos desenvolvedores a geração
do código necessário para a produção de simples relatórios. Outra desvantagem considerável é
a independência de dados totalmente limitada: qualquer tipo de alteração estrutural, por mais
simples que fosse, poderia devastar todos os aplicativos que obtinham dados do banco. Devido
a essas restrições, os modelos hierárquicos e em rede foram, consequentemente, substituídos
pelo modelo de dados relacional na década de 1980.
Modelo Relacional
O modelo relacional foi apresentado, em 1970, por Codd (da IBM), em seu famoso artigo
A Relational Model Data for Large Shared Data Banks (Um modelo relacional de dados para
grandes bancos de dados compartilhados).
A base do modelo relacional é calcada no conceito matemático conhecido como relação.
Na tentativa de diminuir a complexidade da teoria matemática abstrata, podemos pensar uma
relação (também chamada de tabela) como sendo uma matriz composta por linhas e colunas.
O modelo relacional é normalmente implementado por meio de um Sistema de Gerencia-

mento de Banco de Dados Relacionais (SGBDR). Na prática, o SGBDR executa as mesmas funções
básicas fornecidas pelos Sistemas de Gerenciamento de Banco de Dados Hierárquico e de Rede,
incorporando também outras funções que tornam o modelo relacional mais simples de enten-
der e implantar.
Uma das vantagens mais significantes do SGBDR é a maneira de ocultar do usuário as
complexidades do modelo relacional, gerenciando todos os detalhes físicos e permitindo que o
usuário apenas visualize o banco de dados relacional como uma coleção de tabelas nas quais os
dados são armazenados.
Por meio do compartilhamento de um determinado atributo comum (valor de uma colu-
na), as tabelas são relacionadas entre si. A Figura 8 apresenta a tabela nomeada de CLIENTE que
contém um número de corretor, que, por sua vez, também está contida na tabela CORRETOR.
Nome da Tabela: CORRETOR

AGENT_CODE AGENT_NAME AGENT_FNAME AGENT_INITIAL AGENT_AREACODE AGENT_PHONE
501 Alby Alex B 713 123-3456
502 Hahn Leah F 615 245-5455
503 Okon John T 615 234-2353
Ligação por meio de AGENT_CODE
Nome da Tabela: CLIENTE

CUS_INI CUS_AREA_ CUS_INSURE
CUS_CODE CUS_LNAME CUS_FNAME CUS_PHONE ATEND_CODE
TIAL CODE _AMT
10010 Ramas Alfred A 713 123-3456 100 502
10011 Dunne Leona K 615 245-5455 250 501
10012 Smith Kathy W 615 234-2353 313 502
10013 Olowski Paul F 456 456-3434 452 502
10014 Orlando Myron 324 342-5633 346 501
10015 O’Brian Amy B 657 345-3212 466 503
10016 Brown James G 864 345-3456 233 502
10017 Williams George 342 345-5644 322 503
10018 Farriss Anne G 567 246-3344 34 501
10019 Smith Olette K 343 247-3456 455 503
Figura 8 Relacionamento entre tabelas.
O relacionamento entre as tabelas CLIENTE e CORRETOR permite que você relacione o

cliente com seu corretor de vendas, mesmo que os dados dos clientes estejam armazenados em
uma tabela e os dos corretores estejam localizados em outra. Por exemplo, é possível vincular
facilmente o cliente Leona Dunne com seu respectivo corretor, ora identificado como Alex Alby,
pois, para o cliente Leona Dunne, o código AGENT_CODE (código do corretor) da tabela CLIENTE
é 501 (que, por sua vez, corresponde ao AGENT_CODE de Alex Alby na tabela CORRETOR).
Podemos afirmar que o modelo relacional tornou-se a base fundamental de uma revolu-
ção real dos bancos de dados existentes hoje em dia, especialmente pelo fato de incorporar a
poderosa e flexível linguagem de consulta conhecida como SQL (Structured Query Language),
a qual permite que o usuário especifique o que deve ser feito sem a necessidade de especificar
como se deve fazê-lo.
Modelo Entidade-Relacionamento
Embora o modelo relacional represente um aprimoramento em relação aos modelos hie-
rárquico e em rede, alguns recursos ainda eram escassos para que ele fosse avaliado como uma
ferramenta de projeto eficiente. Como é mais objetivo representar estruturas gráficas em vez de
descrevê-las em texto, os projetistas de bancos de dados preferem utilizar a ferramenta gráfica,
pois esta permite que as entidades e seus relacionamentos sejam visualizados de maneira sim-
plificada. Dessa forma, o modelo de entidade-relacionamento (ER) ou MER (ERM, sigla em inglês
para Entity Relationship Model) tornou-se um padrão aceito mundialmente para modelagem de
dados.
O famoso Peter Chen apresentou pela primeira vez, em 1976, o modelo de dados ER, o
qual tratava da representação gráfica clara e intuitiva de entidades e seus respectivos relaciona-
mentos em uma estrutura de banco de dados. Tal representação tornou-se popular, pois com-
plementava de forma satisfatória os conceitos do modelo relacional, o qual foi mesclado com o
MER para construir uma base sólida do projeto de bancos de dados fortemente estruturado. Os
modelos ER são, geralmente, simbolizados por um diagrama de entidade-relacionamento (DER),
que utiliza representações gráficas para modelar os componentes do banco de dados.
Veja, a seguir, os componentes que constituem o modelo ER:
• Entidade: representada no DER por um retângulo, e sua identificação é feita por um
substantivo, escrito de maneira centralizada. Normalmente, é escrito em letras maiús-
culas e no singular: PROFESSOR em vez de PROFESSORES e FUNCIONÁRIO em vez de
FUNCIONÁRIOS. Quando utilizamos o DER no modelo relacional, é frequente que uma
entidade seja mapeada para uma tabela relacional, onde cada linha é nomeada como
instância de entidade ou ocorrência de entidade no modelo ER.
Cada entidade é definida por um conjunto de atributos que descrevem suas caracte-
rísticas específicas. Por exemplo, a entidade FUNCIONÁRIO possuirá como atributos o
nome e data de nascimento.
• Relacionamento: tem como principal objetivo realizar a associação entre os dados.
A grande parte dos relacionamentos faz a conexão (relaciona) entre duas entidades.
Sua identificação, em geral, é realizada por um verbo. São exemplos: um PINTOR pinta
várias PINTURAS; um FUNCIONÁRIO aprende várias HABILIDADES; um FUNCIONÁRIO
gerencia uma LOJA.
Nas Figuras 9 e 10 podem ser visualizados os diferentes tipos de relacionamento. Os dois
casos fazem uso de notações de ER: a notação original de Peter Chen e a notação Crow’s Foot
(pé de galinha), considerada a notação mais atual.
A Figura 9 apresenta a notação de Peter Chen, em que as conectividades (relacionamen-
tos) são descritas próximas a cada entidade. Graficamente, os relacionamentos são represen-
tados por um losango, o qual é conectado às entidades relacionadas por meio de uma reta. A
identificação de um relacionamento é escrito no interior do losango.
Já a Figura 10 ilustra a notação pé de galinha. Esse nome é consequência da utilização do
símbolo de três pontas, o qual representa o lado muitos do relacionamento. Podemos observar
que as conectividades oriundas do DER básico que usa a notação pé de galinha são representa-
das por símbolos. No exemplo, o 1 é representado por um curto segmento de reta e o M, por
uma forca de três "pés de galinha". Também podemos notar que o nome do relacionamento é
escrito sobre a reta do relacionamento.

No exemplo constituinte das Figuras 9 e 10, as entidades e relacionamentos são demons-

trados em um formato horizontal, embora possam ser representados verticalmente. A localiza-
ção, como a ordem de representação das entidades, é irrelevante.
Figura 9 Apresentação da notação de Peter Chen.
Figura 10 Apresentação da notação Pés de Galinha (Crow´s Foot).
Modelo Orientado a Objetos

No modelo de dados orientado a objetos, os dados e seus respectivos relacionamentos
são contidos em uma única estrutura, conhecida como objeto. Como não poderia deixar de ser,
o modelo de dados orientado a objetos constitui a base para o SGBDOO.
Diferente do que ocorre com uma entidade, o objeto também inclui, internamente, in-
formações pertinentes aos relacionamentos entre os fatos, assim como informações sobre os
relacionamentos com outros objetos. Esse tipo de modelo permite que um determinado objeto
possua todas as ações que podem ser executadas sobre ele, como a alteração, a busca ou a im-
pressão de seus dados.
Os seguintes componentes constituem o modelo de dados orientado a objetos:
1) Objeto: abstração de uma entidade real, podendo ser considerado similar à entidade
no modelo de ER.
2) Atributos: descrevem propriedades de um objeto. Exemplo: o objeto PESSOA inclui os
atributos Nome, RG, CPF e Data de Nascimento.
3) Classe: representa um conjunto de objetos comuns, os quais compartilham os atribu-
tos (estrutura) e seus comportamentos (métodos).
4) Método: representa uma ação real. Exemplo: a ação de encontrar uma PESSOA sele-
cionada, alterar o nome da PESSOA ou até mesmo realizar a impressão de seu ende-
reço. Portanto, os métodos correspondem aos procedimentos da linguagem de pro-
gramação tradicional.
5) Hierarquia de classes: assemelha-se a uma estrutura de árvore de cima para baixo,
em que cada classe possui apenas um pai. Por exemplo, as classes CLIENTE e EMPRE-
GADO herdam características compartilhadas de sua classe pai PESSOA (semelhante
ao modelo hierárquico).
6) Herança: destina-se à capacidade de um objeto herdar os atributos e seus respecti-
vos métodos das classes superiores (pai). Por exemplo, podemos citar as duas classes
CLIENTE e FUNCIONÁRIO, as quais podem ser criadas como subclasses da mesma clas-
se PESSOA (pai ou superclasse), herdando todos os atributos e métodos de PESSOA.
A UML (Unified Modeling Language, ou seja, Linguagem de Modelagem Unificada) é uma
linguagem baseada em conceitos de orientação a objetos que descreve um conjunto de diagra-
mas e símbolos utilizados para modelar graficamente um sistema computacional. Ele é usado,
também, para representar o diagrama de classe dos modelos de dados orientados a objetos.
A Figura 11 apresenta os objetos necessários para um cenário simples de faturamento,
bem como o diagrama de classes equivalente em UML e seu respectivo modelo de ER. Os ob-
jetos da FATURA incluem todos os objetos a ela relacionados. Observamos que seus relaciona-
mentos (1 e M) representam a conectividade dos objetos relacionados com a FATURA, em que
o número 1, próximo ao objeto CLIENTE, indica que cada FATURA se relaciona única e exclusiva-
mente com apenas um CLIENTE. Enquanto a letra M, localizada próxima ao objeto LINHA, indica
que cada FATURA contém muitas LINHAS.
O diagrama de classes em UML utiliza três classes distintas de objetos (CLIENTE, FATURA
e LINHA) e dois relacionamentos. É possível notar que as conexões dos relacionamentos são
representadas pelos símbolos 1..1, 0..* e 1..*, em que os relacionamentos são expostos na duas
extremidades permitindo a reprodução de diversos "papéis" que os objetos possam executar.
Já o modelo ER faz uso, também, de três entidades segmentadas e dois relacionamentos para
constituir o mesmo cenário.
Figura 11 Diferenças entre os modelos de OO, UML e ER.
Modelo de Dados Relacionais Estendido

Devido à complexidade incremental das aplicações computacionais, o modelo de dados
relacionais estendido foi criado por meio da utilização dos melhores recursos do modelo orien-
tado a objeto (OO) em um ambiente estrutural de banco de dados relacional. Um SGBD baseado
em um modelo de dados relacional estendido é, geralmente, representado como um Sistema de
Gerenciamento de Bancos de Dados Relacionais/Objeto (SGBDR-O).
Esse modelo destina-se, exclusivamente, a aplicações comerciais, enquanto o modelo de
dados orientado a objeto concentra-se em aplicações científicas e/ou aplicações computacio-
nais específicas (a manipulação e o gerenciamento de imagens médicas, por exemplo).
Para que todo o esquema, as regras armazenadas e controladas pelos SGBDs funcionem
corretamente, é necessário conhecermos os componentes de processamento de consulta e ad-
ministração de memória. Os componentes de processamento de consultas são softwares que
promovem interface, de mais alto nível, entre os usuários – sejam eles DBAs (Database Adminis-
trators), usuários finais ou programas de aplicações (também conhecidos como front-end). Os
componentes incluem:
1) Compilador DML (Data Manipulation Language): realiza a tradução dos comandos
DML em instruções de baixo nível para o componente de execução de comandos.
Possui também a responsabilidade de otimizar, transformando a requisição do usuário

em uma equivalente, porém mais eficiente, de acordo com o projeto implementado
pelo banco de dados. É importante lembrar que os dados de baixo nível são dados no
formato binário ou no formato de linguagem de máquina (a linguagem Assembly, por
exemplo).
2) Pré-compilador para comandos DML: o pré-compilador atua paralelamente com o
compilador DML, traduzindo comandos DML manipulados em programas de aplica-
ção, gerando a codificação adequada.
3) Interpretador DDL (Data Definition Language): realiza a interpretação dos comandos
DDL, armazenando esses registros (metadados) em tabelas internas apropriadas. Me-
tadado é uma abstração do dado capaz, por exemplo, de indicar se determinada base
de dados existe, quais os atributos de uma tabela e suas características (tamanho e/
ou formato).
4) Pré-compilador DML (Data Manipulation Language ou Linguagem de Manipulação
de Dados): compila comandos DML em rotinas da linguagem do host. Precisa interagir
com o processador de consultas para gerar o código apropriado. Host ou Hospedeiro
é qualquer computador capaz de interpretar e executar rotinas de linguagens que
convertam o código-fonte em um código- objeto apropriado, isto é, o compilador da
linguagem interage com o processador, o qual irá dizer sob quais regras o código deve-
rá ser criado e alocado fisicamente, para que este possa ser executado corretamente
pelo host.
5) Componentes para tratamento de consultas: tem como objetivo principal executar
instruções de baixo nível geradas pelo compilador DML.
Figura 12 Sistema Gerenciador de Banco de Dados.
Os componentes de administração de memória são responsáveis pelo gerenciamento de

memória e arquivos do Sistema Gerenciador de Banco de Dados e estabelecem a comunicação
em baixo nível entre os componentes de processamento de consulta e o repositório de dados.
Esses componentes são constituídos pelo:
1) Gerenciador de Autorizações e Integridade: aplicativos que realizam os testes ade-
quados para garantir o cumprimento das regras de integridade e as permissões dos
usuários para acessar os dados.
2) Gerenciador de Transações: garante que os arquivos de dados sejam mantidos de

maneira consistente, independentemente de falhas no sistema ou transações concor-
rentes (executadas paralelamente), evitando conflitos entre os procedimentos.
3) Gerenciador de Arquivos: gerencia a alocação de espaço de armazenamento em dis-
co, como suas estruturas utilizadas para representar as informações.
4) Gerenciador de Buffer: gerencia os dados oriundos do disco (meio de armazenamen-
to), colocando-os na memória principal ou na memória cache.
Além das estruturas apresentadas anteriormente, existem outras estruturas em discos,
implementadas pelo Sistema Gerenciador de Bancos de Dados, consideradas relevantes. São
elas:
1) Arquivos de Dados: seria o banco de dados propriamente dito.
2) Dicionário de Dados: realiza o armazenamento das informações relativas à estrutura
do banco de dados. O dicionário de dados é frequentemente requisitado por várias
aplicações que constituem o SGBD. É importante destacar que o dicionário de dados
é um espaço reservado dentro de um banco de dados, utilizado para armazenar in-
formações sobre o próprio banco de dados. Um dicionário de dados pode conter in-
formações como: informações do banco de dados, procedimentos SQL armazenados,
permissões de usuários, estatísticas do usuário, desempenho e crescimento.
3) Arquivos de Índices: aperfeiçoam o acesso aos dados, auxiliando os algoritmos de
consulta, por meio da indexação de determinados dados contidos no arquivo de da-
dos.
4) Estatística de Dados: arquivo responsável pelo armazenamento de variáveis referen-
tes às estatísticas relativas aos dados. Essas variáveis são utilizadas pelo processador
de consultas para selecionar os meios mais eficientes na realização de uma consulta
específica.
A centralização dos recursos em um SGBD (Figura 12) aumenta a vulnerabilidade do siste-
ma, pois uma falha poderá ocasionar a interrupção das atividades do sistema.
8. ARQUITETURA EM UM SGBD
Vejamos o que Takai; Italiano e Ferreira (2005) dizem sobre a arquitetura em um Sistema
Gerenciador de Banco de Dados.
As primeiras arquiteturas utilizavam mainframes para executar o processamento principal e de todas as
funções do sistema, incluindo os programas aplicativos, os programas de interface com o usuário, bem
como a funcionalidade dos SGBDs. Esta é a razão pela qual a maioria dos usuários fazia acesso aos sis-
temas via terminais que não possuíam poder de processamento, apenas a capacidade de visualização.
Todos os processamentos eram feitos remotamente, apenas as informações a serem visualizadas e os
controles eram enviados do mainframe para os terminais de visualização, conectados a ele por redes
de comunicação.
Como os preços do hardware foram decrescendo, muitos usuários trocaram seus terminais por com-
putadores pessoais (PC) e estações de trabalho. No começo, os SGBDs usavam esses computadores da
mesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade,
execução de programas aplicativos e processamento da interface do usuário eram executados em ape-
nas uma máquina.

Figura13 Arquitetura Cliente-Servidor.
Gradualmente, os SGBDs começaram a explorar a disponibilidade do poder de processamento no lado

do usuário, o que levou à arquitetura cliente-servidor.
A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computação onde um grande
número de PCs, estações de trabalho, servidores de arquivos, impressoras, servidores de banco de da-
dos e outros equipamentos estão conectados juntos por uma rede.
[...]Desta maneira, a arquitetura cliente-servidor foi incorporada aos SGBDs comerciais. Diferentes téc-
nicas foram propostas para se implementar essa arquitetura, sendo que a mais adotada pelos Sistemas
Gerenciadores de Banco de Dados Relacionais (SGBDR) comerciais é a inclusão da funcionalidade de
um SGBD centralizado no lado do servidor. As consultas e a funcionalidade transacional permanecem
no servidor, sendo que este é chamado de servidor de consulta ou servidor de transação. É assim que
um servidor SQL é fornecido aos clientes. Cada cliente tem que formular suas consultas SQL, prover a
interface do usuário e as funções de interface usando uma linguagem de programação.
Figura 14 Sistemas Gerenciadores de Banco de Dados Relacionais.

Comumente o servidor SQL também é chamado de back-end machine e o cliente de front-end machine.
Como o SQL provê uma linguagem padrão para os SGBDRs, esta criou o ponto de divisão lógica entre o
cliente e o servidor.
Atualmente, existem várias tendências para arquitetura de Banco de Dados, nas mais diversas direções.
Por isso, as arquiteturas de SGBDs podem ter as seguintes configurações:

Plataformas centralizadas. Na arquitetura centralizada, existe um computador com grande capacidade
de processamento, o qual é o hospedeiro do SGBD e emuladorres para os vários aplicativos. Esta arqui-
tetura 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.
Figura 15 Plataformas Centralizadas.
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. Desta
maneira, possuem um único aplicativo a ser executado na máquina. A principal vantagem desta arqui-
tetura é a simplicidade.
Figura 16 Sistemas de Computador Pessoal.
Banco de Dados Cliente-Servidor. Na arquitetura Cliente-Servidor, o cliente (front_end) executa as ta-

refas 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 DBMS 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 consulta (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.
Banco de Dados Distribuídos (N camadas). Nesta arquitetura, a informação está distribuída em diver-
sos servidores. [...] 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, independentemente de
conhecer seus servidores.
Exemplos típicos dessa configuração 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.
[...]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 des-
ses dados.
Figura 17 Banco de Dados Distribuídos.
9. CONSULTAS EM UM SGBD
Os Sistemas de Gerenciamento de Bases de Dados foram criados com o objetivo de ma-
nusear corretamente os dados que gerenciam, e as funções mais executadas em um SGBD são:
preservar os dados que são guardados em memória e fornecer recursos que possibilitem a sua
recuperação.
A responsabilidade dos SGBDs no que diz respeito às informações é grande, pois nenhum
dado pode sofrer alterações em seu armazenamento ou em sua recuperação. É comum um
dado ter um caráter modificado devido ao mau funcionamento da memória ou do hardware,
por onde trafegam as informações.
A estrutura de consulta é o fator de maior influência no desempenho de um sistema e
representa grande parte dos problemas, uma vez que todas as funcionalidades que recuperam
dados o fazem por meio de consultas.
Como parte dos desenvolvedores não tem experiência para determinar qual a melhor
forma de se estruturar uma consulta, visto que isso, em geral, depende da plataforma em uso,
esta tarefa quase sempre fica a cargo dos DBAs (Database Administrator ou Administrador de
Banco de Dados).
Existem duas formas de realizar a consulta em uma base de dados:
• utilizando uma linguagem específica de trabalho com base de dados como, por exem-
plo a SQL (Structured Query Language);
• realizando a consulta por meio de exemplo – QBE (Query By Example).
Mas o que seria realizar uma consulta, quando falamos em banco de dados?
Realizar uma consulta é fazer uma pergunta ao banco de dados, especificando alguns cri-
térios, como: "Quais os nomes dos professores cuja disciplina é Matemática?".
Observe como seria a pergunta em SQL:
SELECT NomeProfessor FROM Professores WHERE Disciplina= matemática.
Observe o raciocínio, de acordo com o site Murall (2012), disponível em <http://murall.

com.br/banco-de-dados/>. Acesso em: 23 out. 2012.
O que acontece se a pergunta for feita de forma errada ou tão confusa, capaz de fazer o sistema a se
perder na resposta?
Se a pergunta for incorreta ou confusa o sistema se perde ou, muitas vezes demora em responder ao
que se deseja, causando queda do desempenho de busca de informações do banco de dados, gerando
assim, demora no fornecimento da informação ou erro por não encontrar as respostas. Vale lembrar
que existe um recurso que auxilia na melhoria do desempenho de um dado no processo de busca. Esse
recurso é conhecido por ÍNDEX ou ÍNDICE, que trabalha como indicador da posição que apresenta a in-
formação que está sendo procurada. O tempo de acesso às linhas de uma tabela é acelerado com esse
recurso, pois apresenta ponteiros que indicam o local exato da tabela.
10. QUESTÕES AUTOAVALIATIVAS

Sugerimos que você procure responder, discutir e comentar as questões a seguir que tra-
tam da temática desenvolvida nesta unidade.
A autoavaliação pode ser uma ferramenta importante para você testar o seu desempenho.
Se você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos estu-
dados para sanar as suas dúvidas. Esse é o momento ideal para que você faça uma revisão desta
unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocorre de
forma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus colegas.
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta
unidade:
1) O que é um banco de dados?
2) Sabemos que banco de dados e base de dados não são sinônimos. Explique sua diferença.
3) Defina e exemplifique dados e informação.
4) Como os bancos de dados são classificados? Cite alguns tipos de bancos de dados.
5) Defina um banco de dados temporal.
6) O que é um Sistema Gerenciador de Banco de Dados (SGBD)?
7) Defina os seguintes conceitos:

a) Modelo Conceitual.
b) Modelo Lógico.
c) Modelo Físico.
8) Um desenvolvedor recebe um documento que detalha de maneira precisa e estruturada um banco de dados. O
desenvolvedor deverá criar um software para acessar o banco de dados por meio de um SGBD. Esse documento
é um modelo conceitual, um modelo lógico ou um modelo físico?
9) Defina o modelo entidade-relacionamento (MER), detalhando seus principais componentes.

11. CONSIDERAÇÕES
Nesta unidade, você teve a oportunidade de compreender a importância e a necessidade
indiscutível de um Sistema de Gerenciamento de Banco de Dados no mundo atual, o qual de-
pende da tecnologia para realizar o controle das informações.
Você tem ideia da quantidade de informações que é trocada, armazenada e buscada, dia-
riamente, em todos os setores da sociedade? Pode-se dizer que é algo imensurável. É funda-
mental, portanto, que existam regras, arquiteturas, estruturas com níveis bem definidos e mo-
delos de dados para organizar e controlar essa grande quantidade de informação.
Como futuro projetista de banco de dados, é necessário que você conheça e domine os
modelos conceituais de banco de dados. Na próxima unidade, você estudará o modelo entida-
de-relacionamento, um modelo conceitual amplamente difundido e utilizado pelos projetistas
de bancos de dados.
12. E-REFERÊNCIAS
Lista de figuras
Figura 1 Banco de Dados. Disponível em: <http://segundoepmedici.blogspot.com.br/2011/08/banco-de-dados-br-modelo.
html>. Acesso em: 01 out. 2012.
Figura 17 Banco de Dados Distribuídos. Disponível em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=5530>.
Acesso em: 01 out. 2012.
Sites pesquisados
MURALL. Banco de Dados. Disponível em: <http://murall.com.br/banco-de-dados/>. Acesso em: 23 out. 2012.
TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J. E. Introdução a Banco de Dados. 2005. Disponível em: <http://pt.scribd.com/
doc/51228653/9/Arquiteturas>. Acesso em: 22 out. 2012.
13. REFERÊNCIAS BIBLIOGRÁFICAS

KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. São Paulo: Makron Books, 1998.
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995.
RAMAKRISHNAN, R.; GEHRKE, J. Database management systems. 2. ed. Boston: McGraw-Hill, 2000.
ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementação e Administração. 8. ed. São Paulo: Cengage Learning,
2011.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed. Rio de Janeiro: Elsevier, 2006.
Modelagem dos Dados
utilizando o Modelo
Entidade-Relacionamento
2
1. OBJETIVOS
• Conhecer e analisar as fases de um projeto de banco de dados.
• Desenvolver um projeto conceitual de banco de dados empregando o Modelo Entida-
de-Relacionamento.
• Compreender o Modelo Entidade-Relacionamento Estendido.
2. CONTEÚDOS
• Modelos de banco de dados.
• Definições de objetos do Modelo Entidade-Relacionamento (MER).
• Características adicionais do Modelo Entidade-Relacionamento.
• Projeto conceitual de banco de dados com o Modelo Entidade-Relacionamento.
• Diagrama Entidade-Relacionamento (DER).
• Exemplos de Diagramas Entidade-Relacionamento.
• Modelo Entidade-Relacionamento Estendido (EER).

guir:
1) O conteúdo desta unidade discorre sobre a modelagem de dados utilizando o Modelo

Entidade-Relacionamento. Esse modelo é considerado um modelo clássico, ou seja,
um dos mais utilizados na modelagem de dados.
2) Observe atentamente as definições dos objetos do Modelo Entidade-Relacionamento
(MER), como também suas características adicionais. Isso, sem dúvida, fará diferença
em seu aprendizado, sobretudo na elaboração de bancos de dados bem estruturados.
3) Atente-se ao desenvolvimento do projeto conceitual de banco de dados com a aplica-
ção do Modelo Entidade-Relacionamento. Você vai perceber que somente colocando
a "mão na massa", sua abstração do tema será facilitada.
4) Utilize várias ferramentas para a criação dos DER (Diagrama Entidade-Relacionamen-
to), como o brModelo, Dia etc. Isso facilitará a elaboração dos exercícios propostos.
5) Uma vez que a prática dessa unidade é extremamente importante, faça e refaça,
quantas vezes forem necessárias, os diversos exemplos de diagramas entidade-rela-
cionamento.
6) Antes de iniciar os estudos desta unidade, é interessante que você conheça um pouco
sobre Peter Chen. Por isso, sugerimos que leia a breve biografia apresentada a seguir
e acesse os sites indicados.
Peter Chen
A notação original para o Modelo Entidade-Relacionamento foi proposta por Peter Chen e é
composta de entidades (retângulos), relacionamentos (losangos), atributos (círculos) e linhas
de conexão (linhas) que indicam a cardinalidade de uma entidade em um relacionamento.
Chen ainda propõe símbolos para entidades fracas e entidades associativas (imagem dispo-
nível em: <http://sankofa.loc.edu/savur/web/peterchen.jpg>. Acesso em: 02 out. 2012. Texto
adaptado do site disponível em: <http://erealityhome.wordpress.com/2008/08/23/modelo-enti-
dade-relacionamento-mer-peter-chen-1976-2/>. Acesso em: 02 out. 2012).
Na unidade anterior, você aprendeu que os Sistemas Gerenciadores de Bancos de Dados
foram criados para solucionar os problemas existentes nos sistemas de arquivos, tais como: re-
dundância, inconsistência, compartilhamento e segurança dos dados e das informações.
Nesta unidade, você terá a oportunidade de entender como se desenvolve um projeto
conceitual de um banco de dados por meio do modelo entidade-relacionamento.
Para facilitar a sua compreensão, antes de iniciarmos nossos estudos sobre o modelo en-
tidade-relacionamento, é fundamental que você conheça detalhadamente as fases que com-
põem um projeto de banco de dados e o que é um modelo de banco de dados.
5. MODELOS DE BANCO DE DADOS

Um modelo de banco de dados nada mais é do que uma descrição dos tipos de informa-
ções que serão armazenadas em um banco de dados.
Para que seja possível a construção de um modelo de dados estruturado e consistente, tor-
na-se necessário a utilização de uma linguagem de modelagem de dados. Essas linguagens são
classificadas baseando-se na maneira em que são representados os modelos de dados, por exem-
plo, a representação por meio de linguagens textuais ou gráficas. Tais linguagens são utilizadas
para representar modelos de dados em distintos níveis de abstração e com vários objetivos.
© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento 53
Dessa maneira, um esquema de banco de dados pode ser denominado como sendo uma
representação de um modelo de dados utilizando-se uma linguagem de modelagem de dados
específica.
O objetivo de um modelo de dados é ser útil na explicação, a um usuário leigo em infor-
mática, sobre a organização utilizada em um determinado banco de dados, pois ele não conterá
informações detalhadas sobre a representação física das informações. É diferente do que ocorre
com um modelo de dados usado por um técnico, pois este deverá conter os detalhes sobre a
organização interna das informações e, portanto, será menos abstrato.
Em um projeto de banco de dados, comumente são utilizados dois níveis de abstração: o
modelo conceitual e o modelo lógico.
Modelo conceitual
Um modelo conceitual é uma descrição do banco de dados de forma independente de im-
plementação em um SGBD; trata-se um modelo de dados abstrato. O modelo conceitual regis-
tra quais dados podem aparecer no banco de dados, mas não registra como estes dados serão
armazenados em nível de SGBD; é uma generalização.
Uma das técnicas mais utilizadas mundialmente na modelagem conceitual é a abordagem
Entidade-Relacionamento (ER). Por meio dela, uma modelagem conceitual é normalmente re-
presentada por um diagrama, este denominado Diagrama Entidade e Relacionamento (DER). A
Figura 1 ilustra este modelo:
Figura 1 Exemplo de modelo conceitual.
Entre outras coisas, este modelo nos faz entender que o banco de dados contém dados
sobre produtos e sobre tipos de produtos. Para cada produto, o banco de dados armazena o
código, a descrição e o preço, bem como o tipo de produto em que está associado.
Modelo lógico
Um modelo lógico é uma descrição de um banco de dados no nível de abstração visto pelo
usuário do SGBD, de forma que este modelo é dependente do SGBD que será usado.
Em um modelo lógico, devem ser definidas as tabelas contidas pelo banco e, para cada
tabela, os nomes das colunas, tais como:
TipoDeProduto(CodTipoProd, descTipo)
Produto(codProd, descProd, precoProd, codTipoProd)

O modelo lógico descreve a estrutura do banco de dados, conforme vista pelo usuário di-
reto do SGBD. São detalhes de armazenamento interno de informações, que não têm influencia
sobre a programação de aplicações no SGBD, mas podem afetar o desempenho da aplicação.
Fases do projeto de banco de dados

Vimos, anteriormente, que o minimundo representa o domínio relacionado aos dados
que o banco deve armazenar. Um levantamento dos requisitos desse minimundo é efetuado
e, a partir da análise de requisitos, é criado o projeto conceitual, representado pelo modelo
entidade-relacionamento, o qual não contém detalhes de implementação. Trata-se, portanto,
de um modelo de dados de alto nível, e independente do SGBD a ser adotado.
A próxima etapa refere-se à criação do projeto lógico, que é realizada por meio do mape-
amento do modelo entidade-relacionamento para o modelo relacional. A partir dessa fase, já se
pensa em um modelo de dados de implementação do SGBD.
Por fim, a última etapa corresponde à fase do projeto físico, quando são definidos as
estruturas de armazenamento interno, os índices, além de outras atividades desenvolvidas pa-
ralelamente, como a implementação dos programas de aplicação.
6. DEFINIÇÕES DE OBJETOS DO MODELO ENTIDADE-RELACIONAMENTO

(MER)
Você já ouviu falar em modelo entidade-relacionamento?
Pois bem, o modelo entidade-relacionamento (MER) foi criado por Peter Chen na década
de 1970, podendo ser considerado um padrão para a modelagem conceitual. Esse modelo é
baseado na percepção do mundo real e tem como finalidade a construção de objetos denomi-
nados entidades e a promoção do relacionamento entre eles.
O MER tem o objetivo de descrever, de maneira conceitual, os dados que serão utilizados
em um sistema de informações.
O modelo possui conceitos intuitivos que permitem aos projetistas de bancos de dados
capturarem os conceitos inerentes aos dados da aplicação, independente de qualquer tecnolo-
gia utilizada para desenvolvimento de bancos de dados. O esquema conceitual criado utilizan-
do-se os conceitos do modelo entidade-relacionamento é denominado de diagrama entidade-
-relacionamento (DER).
Veja, a seguir, a representação do diagrama entidade-relacionamento.
Nome
Idade
Código Professor
Código
(1, M) Telefone Rua
Nome
leciona Curso Endereço Número

Título
Aluno Código Bairro

(1, M) (1, M)
Nome
Disciplina Possui
Código
Sexo
(1, M) (1, M)
Nome
Nascimento
oferecida (1, M)
Turma (1, M)
matricula-se
(1, M)
Código Número Alunos
Período Letivo Data Matrícula
Início Data Cancelamento
Término Motivo Cancelamento
Figura 2 Diagrama Entidade-Relacionamento.
O diagrama entidade-relacionamento é composto por entidades, atributos e relaciona-

mentos. As entidades representam objetos do mundo real; os atributos representam suas ca-
racterísticas; e os relacionamentos, a forma como esses objetos estão ligados entre si.
Embora o diagrama entidade-relacionamento possua um elemento chamado entidade,
representado por um retângulo, ele não tem relação com a entidade externa do diagrama de
fluxo de dados.
Entidade
Uma entidade é um objeto existente e distinto de qualquer outro objeto. Ela tem por fi-
nalidade representar um conjunto de objetos da realidade modelada. Por exemplo, uma pessoa
chamada João da Silva possui um número de RG único, RG nº. 12.345.678-SP; este número de
RG é uma entidade, uma vez que identifica a pessoa de uma forma única em relação às outras
pessoas. Uma entidade pode ser concreta, como uma pessoa ou uma empresa, ou abstrata,
como um conceito.
Dessa forma, podemos perceber que um conjunto de entidades é um grupo de entidades
do mesmo tipo. O conjunto de alunos de sua turma, por exemplo, pode ser definido como o
conjunto de entidades ALUNOS.
Em um DER, uma entidade é representada por um retângulo que contém seu nome, con-
forme demonstrado na Figura 3:
Figura 3 Representação gráfica de entidades.

Relacionamento
Uma das propriedades sobre as quais pode ser desejável manter associações é a associa-
ção entre objetos. Na Figura 3, por exemplo, pode ser válido conhecer apenas as pessoas de um
dado departamento. Logo, uma pessoa tem de estar associada a um departamento para que
esta classificação obtenha êxito.
No modelo de representação DER, um relacionamento é apresentado por meio de um
losango, ligado por linhas aos retângulos.
A Figura 4 demonstra o relacionamento existente entre as entidades FUNCIONÁRIO e PESSOA:
Figura 4 Representação gráfica de relacionamento.
A partir do relacionamento entre as entidades (Figura 4), é possível nos referirmos a asso-
ciações específicas dentro de um conjunto. No caso do relacionamento ASSOCIAÇÃO, uma ocor-
rência seria um par específico formado por uma determinada ocorrência da entidade PESSOA e
por outra da entidade DEPARTAMENTO.
Um relacionamento não ocorre, necessariamente, entre entidades diferentes. Também é
possível um relacionamento entre ocorrências de uma mesma entidade, ou seja, o autorrelacio-
namento (conforme demonstrado na Figura 5).
Figura 5 Demonstração do autorrelacionamento.
Para se entender melhor o conceito de autorrelacionamento, é importante compreender

o conceito de papel da entidade no relacionamento.
Papel de entidade em relacionamento exerce a função que uma instância da entidade
cumpre dentro de uma instância do relacionamento.
No exemplo do relacionamento de CASAMENTO, uma ocorrência de pessoa exerce o papel
de marido e a outra ocorrência de pessoa exerce o papel de esposa.
Cardinalidade de relacionamentos
Um diagrama entidade-relacionamento pode definir restrições com as quais o banco de
dados deve estar de acordo. Uma dessas restrições é a cardinalidade do mapeamento, que ex-
pressa o número de entidades relacionadas a outras entidades por meio de um conjunto de
relacionamentos.
Tomemos por referência o DER representado pela Figura 4. Considere as cardinalidades
máximas:
1) A entidade PESSOA tem cardinalidade máxima 1 no relacionamento ASSOCIAÇÃO. Isso
significa que uma ocorrência de PESSOA pode estar associada à, no máximo, uma
ocorrência de DEPARTAMENTO ou, em outras palavras, que um empregado pode estar
associado à, no máximo, um departamento.
2) A entidade DEPARTAMENTO tem cardinalidade máxima 120 no relacionamento ASSO-

CIAÇÃO. Isso significa que uma ocorrência de DEPARTAMENTO pode estar associada
à, no máximo, 120 ocorrências de PESSOA, ou seja, um departamento pode associar
apenas 120 pessoas.
3) A cardinalidade máxima é 1.
4) A cardinalidade máxima ilimitada, usualmente chamada de cardinalidade máxima
"muitos" é referia pela letra n ou m.
(1, M) (1, M)
Código Disciplina leciona Professor Código
Nome
Nome
Título
Figura 6 Cardinalidade de Mapeamento.
No exemplo demonstrado na Figura 6, temos as cardinalidades mínima e máxima para

o relacionamento. Observe que um ALUNO pode MATRICULAR-SE em várias TURMAS, e uma
TURMA pode ter vários ALUNOS MATRICULADOS. Portanto, a cardinalidade máxima desse rela-
cionamento é muitos-para-muitos.
Veja os tipos de relacionamentos entre entidades binárias:
• Um-para-um: uma entidade de EMPREGADO está associada a apenas uma entidade de
MESA, conforme a Figura 7:
1 1
Figura 7 Relacionamento 1:1.
• Um-para-muitos: uma entidade de CURSO está associada a muitas entidades de ALU-

NO; entretanto, uma entidade de ALUNO está associada a apenas uma entidade de
CURSO (Figura 8):
N 1
Figura 8 Relacionamento 1:N.
• Muitos-para-muitos: uma entidade de MÉDICO está associada a qualquer quantidade

de entidades de PACIENTE, e uma entidade de PACIENTE está associada a qualquer nú-
mero de entidades de MÉDICO, conforme ilustrado na Figura 9:
N N
Figura 9 Relacionamento N:N.

Relacionamento ternário
Até o momento, os exemplos demonstraram relacionamentos binários, ou seja, entre ape-
nas duas entidades. A abordagem ER permite maiores graus entre as relações, como pode ser
observado na Figura 10, na qual temos um exemplo de relacionamento ternário:
Figura 10 Relacionamento ternário.
No relacionamento nomeado de DISTIBUIÇÃO, cada ocorrência vincula outras três ocor-

rências de entidade, isto é, um produto a ser distribuído, uma cidade na qual é realizada a distri-
buição, e por fim, um distribuidor. Quando possuímos relacionamentos superiores a dois (biná-
rios), como ternário e "n"ário a cardinalidade é semelhante à cardinalidade de relacionamentos
binários, ou seja, quando temos um relacionamento ternário, a cardinalidade trabalha com pa-
res de entidades. Para exemplificar, imagine a existência de um relacionamento identificado de
R entre as entidades X, Y e Z. A cardinalidade máxima obtida entre X e Y dentro de R indica a
quantidade de ocorrências de Z que podem estar vinculadas a um par de ocorrências de X e Y.
De acordo com o relacionamento verificado na Figura 11, o número 1 na linha que liga o
retângulo representativo da entidade DISTRIBUIDOR ao losango representativo do relaciona-
mento expressa que cada par de ocorrências (CIDADE, PRODUTO) está associado a, no máximo,
um distribuidor.
N 1
Figura 11 Cardinalidade em relacionamento ternários.

Generalização/especialização
Não nós limitamos apenas aos relacionamentos e seus atributos, podemos ainda abstrair-
mos propriedades à entidades por meio do uso do conceito de generalização/especialização.
Parece complicado? Não tanto! Isso nos permite atribuir propriedades específicas a um sub-
conjunto de ocorrências (especialização) de uma entidade considerada genérica. A simbologia
utilizada para representar generalização/especialização é um triângulo isósceles, conforme você
pode visualizar na Figura 12. Nessa mesma figura, o conceito de generalização/especialização
sinaliza que a entidade CLIENTE é segmentada em dois subconjuntos, esses representados pelas
entidades nomeadas respectivamente de PESSOA FÍSICA e PESSO JURÍDICA, em que cada uma
possui propriedades específicas.
Figura 12 Exemplo de generalização/especialização.
Ao analisar a Figura 12 podemos observar a aplicação do conceito de herança, por meio

do seguinte raciocínio, baseado no paradigma da orientação a objetos: PESSOA FÍSICA é um
CLIENTE, da mesma forma que PESSOA JURÍDICA, pois, ambos os subconjuntos herdam carac-
terísticas gerais da entidade CLIENTE, e em conformidade com o tipo do cliente, acrescentam
propriedades específicas.
A aplicação da generalização/especialização implica que a entidade PESSOA FÍSICA, além
de possuir suas características específicas, possui também todas aquelas contidas da entidade
CLIENTE, ou seja, a entidade PESSOA FÍSICA possui os seguintes atributos: CIC, sexo, nome e
código, sendo os dois últimos provenientes da entidade genérica CLIENTE.
De modo similar, a entidade PESSOA JURÍDICA, possui os seguintes atributos: CGC, tipo de
organização, bem como o nome e código, sendo estes, oriundos da entidade CLIENTE.
Ao fazermos uso da generalização/especialização, esta pode ser classificada nos seguintes
tipos: total ou parcial. Esta classificação dá-se mediante a obrigatoriedade ou não, dos atributos
de uma entidade genérica fazer correspondência à ocorrência de uma entidade especialista.
A classificação total implica que, sempre que houver um registro na entidade genérica,
CLIENTE, deverá implicar em um registro em uma das entidades especialistas. Tomando como
exemplo o diagrama expresso na Figura 12, sempre que houver uma ocorrência de um CLIEN-
TE, espera-se que uma ocorrência de PESSOA FÍSICA ou PESSOA JURÍDICA se realize também. A
classificação total pode ser indicada graficamente na modelagem, por meio da inserção de um t
como símbolo, conforme indicado na Figura 13.

Figura 13 Exemplo de generalização/especialização total.
Uma vez que entendemos o processo de generalização/especialização total, entendere-

mos, agora, como a parcial funciona. A classificação parcial implica que nem toda ocorrência
de registros na entidade genérica deve possuir uma ocorrência em algum dos subconjuntos
pertinentes (entidades especialistas). De forma análoga à generalização/especialização total, a
parcial é representada no diagrama na forma de letra p. Veja, na Figura 14, a aplicação.
Como você pode observar na Figura 14, e seguindo o conceito de parcialidade, entende-se
que nem todo FUNCIONARIO necessariamente deve ser também um MOTORISTA ou uma SE-
CRETARIA, ou seja, o conceito inverso ao conceito de totalidade. Geralmente na especialização
parcial verifica-se um atributo na entidade genérica que tem por finalidade identificar o tipo de
ocorrência. Em especializações totais, este atributo normalmente é dispensável, pois há a cer-
teza de que a existência de um registro na entidade genérica está necessariamente associada a
um registro em uma entidade especialista qualquer.
Figura 14 Exemplo de generalização/especialização parcial.
A especialização de entidades, a priori, não é limitada quanto a quantidade de entidades

especialistas, podendo ser a partir de 1 até N. Analisando o diagrama na Figura 14, podemos
perceber que se a entidade SECRETARIA não apresentar atributos característicos a sua desig-
nação, a existência da mesma seria desnecessária, permanecendo assim apenas uma entidade
especialista MOTORISTA.
É importante ressaltar que também não se verifica limitação quanto ao número de hie-
rarquias, ou níveis hierárquicos. Ou seja, uma entidade já especialista de uma genérica também
pode conter outras entidades que são especialistas desta. Por exemplo, a entidade MOTORISTA
é uma especialização da entidade FUNCIONÁRIO, todavia, nada impede que a entidade MOTO-
RISTA tenha outras entidades especialistas.
Nesse relacionamento, a generalização/especialização exclusiva, é aplicado quando da ne-
cessidade que uma ocorrência de uma entidade genérica, seja associada a uma e apenas uma
entidade especialista. A Figura 15 demonstra o emprego desta necessidade, tomando como re-
ferencial a entidade AUTOMOVEL, observamos que esta é uma entidade especialista de VEICULO
TERRESTRE, e esta é especialista da entidade VEICULO. Considerando os conceitos aprendidos
até o momento, podemos dizer que a entidade AUTOMOVEL possui além de suas propriedades
específicas, as propriedades de VEICULO TERRESTRE e VEICULO.
Figura 15 Exemplo de generalização/especialização com múltiplos níveis de herança.
Entidade associativa
Até agora, você pôde compreender que um relacionamento nada mais é que associações
entre uma ou mais entidades; o DER que empregamos para a construção do modelo de dados
não previu situações em que fosse possível associar uma entidade diretamente a um relaciona-
mento. Outro contexto que também não se faz possível é a associação de dois relacionamentos,
um com o outro.
No uso cotidiano das ferramentas e técnicas de modelagem de dados, frequentemente
nos deparamos com situações em que se faz necessário os relacionamentos descritos. Nos apro-
fundaremos nessa assunto, para isso, observe a Figura 16.
Ao analisarmos a Figura 16 verificamos a relação N:N, por meio do relacionamento CON-
SULTA entre MEDICO e PACIENTE, ou seja, um médico pode consultar vários pacientes, e um
paciente pode ser consultado por vários médicos. Em cada uma das consultas, provavelmente,
medicamentos serão prescritos aos pacientes. Vamos supor que seja necessário catalogar cada
medicamento indicado nas consultas, no primeiro momento, você pode estar pensando em
constituir uma outra entidade, algo como MEDICAMENTO. Até então tudo bem, mas pense,
onde deve ser realizado o relacionamento com a nova entidade? Com a entidade MEDICO ou
PACIENTE? Se relacionarmos a nova entidade, MEDICAMENTO, com a entidade MEDICO, sa-
beríamos apenas os medicamentos prescritos por determinado médico, sem a indicação do
paciente. Caso associássemos com PACIENTE saberíamos quais medicamentos foram prescritos
para cada PACIENTE mais não saberíamos qual foi o médico. A solução para o problema seria re-
lacionarmos a entidade MEDICAMENTO com a CONSULTA, onde será possível obter informações
tanto do médico quanto do paciente.
Para suprir a necessidade de relacionar uma entidade diretamente com um relacionamen-

to foi criado o conceito de entidade associativa. O conceito de entidade associativa é simples, é
uma redefinição do relacionamento existente, onde este passa a assumir o papel de uma entida-
de. Para indicarmos graficamente, basta adicionar um retângulo em torno do losango indicativo
do relacionamento, como demonstrado na Figura 16.
Uma entidade associativa nada mais é do que a redefinição de um relacionamento, que
passa a ser tratado como se fosse também uma entidade. Graficamente, isso é feito como mos-
trado na Figura 16. Veja:
Figura 16 Exemplo de entidade associativa.
Observe que até então apenas relacionamento CONSULTA passou a ser considerado como
uma entidade associativa e, para identificarmos isto, existe a figura do losango no entorno do
relacionamento CONSULTA. Neste momento, o relacionamento passa a ser entendido em con-
formidade com o conceito de entidade, como uma entidade pode ser associada a outras, o
problema que descrevemos anteriormente está resolvido. Basta que a entidade MEDICAMENTO
seja associada à entidade associativa CONSULTA, por meio do relacionamento PRESCRICAO.
Tipos de atributos
Após conhecer a definição de atributos, veja, no Quadro 1, os vários tipos de atributos e
suas aplicações específicas.
Quadro 1 Descrição dos Tipos de Atributos.

TIPOS DE ATRIBUTOS DESCRIÇÃO
É um atributo que contém uma informação atômica, ou seja, uma informação que não pode ser
Atributo Simples
subdividida
É um atributo que contém várias informações que podem ser decompostas e separadas em
outros atributos, e devem ser do tipo simples, ou seja, indivisíveis. Vejamos, por exemplo, o
atributo Endereço, que, provavelmente, conterá uma informação do tipo Rua das Margaridas,
125 – Jardim Primavera – Green Ville. Em alguns casos, o endereço pode conter o CEP e o Estado,
embora seja menos comum. Esse atributo é conhecido como atributo composto, pois pode ser
dividido em cinco atributos, a saber:
Atributo Composto tipo do logradouro: Rua;
logradouro: das Margaridas;
número: 125;
bairro: Jardim Primavera;
cidade: Green Ville.

TIPOS DE ATRIBUTOS DESCRIÇÃO

Este atributo pode receber muitos valores para uma única entidade. Um exemplo clássico deste
tipo de atributo é o número de telefone de uma pessoa. Atualmente, é comum a pessoa possuir
telefone fixo e celular. Nesse caso, dizemos que o atributo Telefone é um atributo multivalorado.
Atributo Multivalorado
Outro exemplo para esse caso é um atributo para armazenar o e-mail de uma pessoa. É bastante
comum uma pessoa possuir mais de um endereço de e-mail e, portanto, este também pode ser
considerado um atributo multivalorado.
Este atributo representa uma informação que pode ser obtida por meio de um processamento
no banco de dados. Vejamos: se você tem uma entidade chamada Pedido e nela é criado
um atributo para armazenar o Total do Pedido, este atributo (Total do Pedido) é um atributo
derivado porque seu valor pode ser obtido multiplicando-se a quantidade do produto pelo preço
Atributo Derivado unitário para cada produto constante no pedido.
ATENÇÃO!
O valor nulo é utilizado quando o atributo não tem um valor aplicável ou quando seu valor é
desconhecido. É importante frisar que NULO (Null) não é 0 (zero).
Toda entidade deve ter, ao menos, um atributo-chave que será utilizado para identificá-la de
forma única, não importando se este atributo é simples ou composto.
Atributo-Chave
Considere, como exemplo, uma entidade de Pessoas: pode ser um atributo-chave o RG, o CPF ou
um código.
Um atributo correlaciona informações à ocorrência de entidades ou até mesmo de rela-

cionamentos. Normalmente, os atributos são representados graficamente, conforme você pode
visualizar na Figura 17, entretanto, na prática isso não é aplicado devido a possibilidade de so-
brecarregar os diagramas, visto que, frequentemente, as entidades podem possuir um grande
número de características.
Figura 17 Atributos de uma entidade.
Do mesmo modo que entidades podem possuir atributos, relações também podem apre-
sentá-los. A Figura 18 mostra um DER, no qual um relacionamento, ATUAÇÃO, possui um atribu-
to, a função que um engenheiro exerce dentro de um projeto:
Figura 18 Atributo de relacionamento n:n.

7. CARACTERÍSTICAS ADICIONAIS DO MODELO ENTIDADE-RELACIONAMENTO

As entidades do modelo entidade-relacionamento são classificadas em entidades e enti-
dades-fracas. Entidades são aquelas que não dependem de nenhuma outra entidade e entida-
des-fracas são as dependentes de outra entidade.
Todavia, duas ou mais entidades podem ser associadas por meio de um relacionamento,
no qual devem estar indicadas as Cardinalidades de Mapeamento do Relacionamento. As cardi-
nalidades expressam a quantidade de entidades associadas.
Tipos de entidade
As entidades têm um ou mais atributos-chave que, juntos, a identificam de forma única.
Porém, alguns tipos de entidade não possuem atributos-chave e são chamados de entidades-
-fracas.
As entidades-fracas, em síntese, dependem de outras entidades. Sua identificação é possí-
vel por meio da associação dos atributos-chave da entidade proprietária e de sua chave parcial.
Em algumas situações, uma entidade-fraca pode ser substituída por atributos multivalorados.
Observe, na Figura 19, um exemplo de entidade-fraca. A entidade DEPENDENTE é uma
entidade-fraca, pois depende de um FUNCIONÁRIO.
(1, M) (1, 1)
Funcionário possui Dependente
Nome
Código
Sexo
Nome
Data Nascimento
Figura 19 Entidade-Fraca.
8. PROJETO CONCEITUAL DE BANCO DE DADOS COM O MODELO ENTIDADE-

-RELACIONAMENTO
A partir deste tópico, você acompanhará o desenvolvimento de um diagrama entidade-
-relacionamento para um sistema de bancos de dados. Mas, primeiro, é necessário que você
conheça os símbolos utilizados em um DER.
Quadro 2 Símbolos utilizados em um modelo-relacionamento.

ELEMENTO SÍMBOLO DESCRIÇÃO
Entidade Representada por um retângulo.

ELEMENTO SÍMBOLO DESCRIÇÃO
Representada por um retângulo

Entidade-Fraca
com linhas duplas.
Relacionamento Representado por um losango.
Atributo Simples Representado por uma elipse.
Representado por uma elipse com

Atributo Multivalorado
linhas duplas.
Representado por uma elipse com

Atributo Derivado
linhas tracejadas.
Representado pela junção de vários

Atributo Composto atributos que podem ser simples,
compostos ou derivados.
Representado por uma elipse, como

Atributo-Chave CHAVE o atributo simples, e o texto deve
estar sublinhado.
Observe, na Figura 20, um exemplo de diagrama entidade-relacionamento.

Idade
Telefone Rua
Endereço Número
(1, M) matricula-se (1, M)
Turma Aluno Código
Bairro
Nome
Código
Sexo
Período Letivo
Nascimento
Início
Número Alunos
Término
Data Matrícula
Data Cancelamento
Motivo Cancelamento
Figura 20 Diagrama Entidade-Relacionamento.

9. DIAGRAMA ENTIDADE-RELACIONAMENTO (DER)

Agora que você conhece os símbolos utilizados em um diagrama entidade-relacionamen-
to, é fundamental compreender que este deve ser construído com base nos dados obtidos com
o usuário na fase de Análise do Sistema de Informação. Após obter todas as informações neces-
sárias (os requisitos), inicia-se a construção propriamente dita do DER.
Para desenvolver o DER para um Sistema Escolar, é preciso definir as entidades (Professor,
Disciplina, Turma, Curso e Aluno) que serão utilizadas no projeto do banco de dados, as quais
são representadas por um retângulo. Veja que o nome de uma entidade é sempre um substan-
tivo no singular.
Pressman (1995, p. 324) propõe seis regras para a definição de objetos para modelos
orientados a objetos, que podem ser aplicadas para as entidades dos bancos de dados relacio-
nais com grande sucesso. Confira a seguir:
Informação Retida: o objeto em potencial será útil durante a análise se a informação sobre ele precisar
ser lembrada de forma que o sistema possa funcionar.
Exemplo: Aluno, Curso.
Serviços Necessários: o objeto em potencial deve ter um conjunto de operações identificáveis que po-
dem mudar o valor de seus atributos de alguma maneira.
Exemplo: Inclusão, Alteração.
Múltiplos Atributos: durante a análise de requisitos, o foco deve recair sobre informações "importantes",
um objeto com um único atributo pode, de fato, ser útil durante a fase de projeto, mas provavelmente ele
será mais bem representado como um atributo de um outro objeto durante a atividade de análise.
Exemplo: estoque (Quantidade). Este atributo ficaria mais bem modelado como o atributo QUANTIDA-
DE_ESTOQUE da entidade PRODUTO.
Atributos Comuns: os atributos definidos para um objeto em potencial; esses atributos aplicam-se a
todas as ocorrências do objeto.
Exemplo: na entidade ALUNO, o atributo NUMERO_RESERVISTA não se encaixaria em todas as ocor-
rências, pois esse documento é solicitado apenas a alunos do sexo masculino. O ideal, nesse caso, é
repensar o modelo e remover esse atributo da entidade ALUNO.
Operações Comuns: as operações definidas para um objeto em potencial; essas operações aplicam-se
a todas as ocorrências do objeto.
Exemplo: as operações Inclusão ou Alteração podem ser feitas em todas as ocorrências da entidade
ALUNO.
Requisitos Essenciais: entidades externas que aparecem no espaço problema e produzem ou conso-
mem informações que são essenciais à operação de qualquer solução para o sistema quase sempre
serão definidas como objetos no modelo de requisitos.
Exemplo: a entidade externa ALUNO, que certamente estaria definida no DFD, consome e gera informa-
ções no sistema e, portanto, foi especificada como uma entidade no Diagrama Entidade-Relacionamento.
Nas regras definidas por Pressman, troque objeto por entidade e você perceberá que elas
se aplicam totalmente.
Após definir as entidades, é preciso compreender que os atributos são representados por
elipses. Lembre-se que o atributo é um substantivo no singular, assim como a definição de uma
entidade. Ele pode ser:
1) simples: linha contínua;
2) composto: quando têm mais atributos ligados a si;
3) chave: quando o nome do atributo está sublinhado;
4) multivalorado: quando as linhas são duplas;
5) derivado: quando as linhas são tracejadas.
Para definir quais atributos adicionar a uma entidade, o projetista de bancos de dados uti-
liza como critério as informações necessárias obtidas no levantamento realizado com o usuário
que solicitou o sistema de informações.
Lembre-se de que os relacionamentos são representados por losangos e podem ser utili-
zados para nomear verbos, advérbios ou preposições, de modo que a sequência das entidades
tenha sentido, quase como uma frase.
Veja o caso do relacionamento leciona entre as entidades PROFESSOR e DISCIPLINA. Len-
do-se como uma frase, temos: PROFESSOR-LECIONA-DISCIPLINA. Outro exemplo é o relacio-
namento matricula-se, entre ALUNO e TURMA. Lendo-se a partir da entidade ALUNO, temos:
ALUNO-MATRICULA-SE-TURMA.
10. EXEMPLOS DE DIAGRAMAS ENTIDADE-RELACIONAMENTO

Veja, a seguir, alguns exemplos de diagramas entidade-relacionamento:
a) Sistema Escolar:
Nome
Idade
Código Professor
Código
(1, M) Telefone Rua
Nome

Título

(1, M) (1, M)
Nome
Disciplina Possui
Código
Sexo
(1, M) (1, M)
Nome
Nascimento
oferecida (1, M)
Turma (1, M)
matricula-se
(1, M)
Figura 21 Diagrama Entidade-Relacionamento para um Sistema Escolar.
O exemplo anterior representa o projeto de um banco de dados simples para uma

escola. Na entidade ALUNO, podemos observar alguns detalhes, tais como: o atributo
TELEFONE é multivalorado (elipse com borda dupla), pois o aluno pode ter telefone
fixo, celular, de recados etc.; o atributo ENDEREÇO é composto, pois é formado por
Rua, Número e Bairro.
No relacionamento MATRICULA-SE, há o atributo derivado NÚMERO ALUNOS. Esse
atributo não será criado na estrutura das tabelas do futuro banco de dados, porque
essa informação pode ser obtida a partir da contagem dos alunos matriculados na
turma e certificando-se que a data de cancelamento esteja vazia (null).
Dessa forma, percebemos que a data de matrícula é um atributo multivalorado, pois
o aluno pode se matricular em várias turmas e, para cada matrícula é gravada a data
em que ela foi efetivada.

b) Controle de Estoque:
Figura 22 Diagrama Entidade-Relacionamento para um sistema de controle de estoque.
Neste exemplo, temos o controle de estoque de produtos de uma empresa de com-

pra e venda. Na entidade COMPRA, há um atributo derivado VALOR_TOTAL, que re-
presenta o valor total de todos os produtos comprados. No relacionamento POSSUI
também há um atributo derivado chamado VALOR_TOTAL_PAGO, que é resultado da
multiplicação dos atributos QTDE_COMPRADA e PREÇO_PAGO. Como você pode per-
ceber, uma solução semelhante é observada na entidade VENDA e no relacionamento
VALOR_TOTAL_COBRADO.
c) Projetos de um Departamento:
Figura 23 Diagrama Entidade-Relacionamento para um sistema de gerenciamento de projetos.
Na Figura 23 temos a representação dos empregados que trabalham em um depar-

tamento, bem como dos projetos em que eles trabalham. Observe que há uma enti-
dade-fraca chamada DEPENDENTE, que representa os cônjuges, filhos e outros que
possam depender legalmente do funcionário. Essa é uma entidade-fraca, uma vez que
não há a necessidade de registrar as informações dos dependentes se antes não fo-
rem registradas as informações do empregado.
Nesse diagrama há, também, um autorrelacionamento na entidade EMPREGADO,
que representa qual empregado é o supervisor dos demais. Fique atento, pois, nesse
exemplo, foram indicadas apenas as cardinalidades máximas.
d) Atendimento a Pacientes:
Figura 24 Diagrama Entidade-Relacionamento para um sistema de controle de pacientes.
Nesse exemplo, temos como característica marcante a agregação, que é o retângulo

existente em MÉDICO atende PACIENTE. Ela foi utilizada porque a RECEITA, que é uma
entidade-fraca, somente passa a existir depois que o médico atende o paciente. Antes
disso, não há a necessidade da receita. A cardinalidade mínima nesse relacionamento
é 0 (zero), pois existem consultas que não necessitam de receitas de medicamentos.
Você sabe por que, nesse caso, foi utilizada uma agregação?
Ela foi utilizada porque a entidade-fraca RECEITA precisa se relacionar com o relaciona-
mento ATENDE (que contém as informações de qual médico atendeu qual paciente).
Além disso, devemos nos lembrar de que não é permitido haver um relacionamento
com outro relacionamento. Assim, agrega-se o relacionamento com suas entidades
participantes e relaciona-se a entidade-fraca com a agregação.
11. MODELO ENTIDADE-RELACIONAMENTO ESTENDIDO (EER)

Quase todas as aplicações de bancos de dados podem ser representadas por meio do
modelo entidade-relacionamento. Entretanto, alguns bancos de dados são mais complexos e
exigem, para sua melhor representação, alguns aspectos adicionais.
Para solucionar esse problema, o modelo ER é expandido para o modelo EER. Esse modelo
inclui, além dos novos conceitos, todos os conceitos de modelagem do modelo ER.
Veja, a seguir, os conceitos relacionados ao modelo EER.
Subclasse
Estudamos, anteriormente, que um conjunto de entidades possui entidades do mesmo
tipo, caracterizando um tipo entidade. Ao pensar em um banco de dados de uma universidade,
consideramos que ALUNO seja um tipo entidade. Se pudermos dividir os alunos em alunos de
graduação e alunos de pós-graduação, teríamos, então, duas subclasses de ALUNO, ou seja, as
subclasses ALUNOGRAD e ALUNOPOSGRAD.
Superclasse
De acordo com o exemplo anterior, podemos dizer que ALUNO é superclasse de ALUNO-
GRAD e ALUNOPOSGRAD.
Herança
Ao conceito de superclasse e subclasse está associado o conceito de herança. Isso significa
que uma entidade de uma subclasse representa a mesma entidade da superclasse, ou seja, os
membros de uma subclasse herdam todos os atributos e relacionamentos da sua superclasse.
No exemplo do banco de dados de uma universidade, isso indica que todo aluno de gra-
duação é um aluno, e que todo aluno de pós-graduação também é um aluno. Cada membro de
ALUNOGRAD e de ALUNOPOSGRAD herda todos os atributos definidos para ALUNO, assim como
seus relacionamentos. Vale lembrar, ainda, que os atributos das subclasses de uma mesma su-
perclasse são diferentes, e que uma subclasse pode se relacionar com uma classe que não se
relaciona com outra subclasse da mesma superclasse.
Especialização
Entende-se por especialização a definição de um conjunto de subclasses de um tipo de
entidade, a partir de uma superclasse.
Generalização
Generalização é a definição de um tipo entidade (superclasse) a partir de suas subclasses,
ou seja, com base nas características comuns a todas as subclasses cria-se uma superclasse, e
essas características são atribuídas apenas à superclasse.
Observe exemplos de generalização nas Figuras 25 e 26.
nome
posgrad
RA
ALUNOPOSGRAD
anodefesa
endereco
turno
curso
ALUNOGRAD
RA
turma
nome endereco
Figura 25 Dois tipos de entidade em Processo de Generalização.

nome
RA
endereco
ALUNO
curso
ALUNOGRAD ALUNOPOSGRAD
turma
turno
posgrad
anodefesa
Figura 26 Generalizando ALUNOGRAD e ALUNOPOSGRAD na superclasse ALUNO.
A Figura 26 também pode ser considerada uma Especialização, caso essa especialização
esteja sendo definida pelo atributo TIPOALUNO, por exemplo.
Uma especialização pode ser definida por predicado, quando há uma condição no valor
de algum atributo da superclasse. É o caso explicado no parágrafo anterior, ou seja, um aluno
pertencerá à subclasse ALUNOGRAD ou ALUNOPOSGRAD dependendo do valor contido no atri-
buto TIPOALUNO.
Quando não existe essa condição, dizemos que a subclasse é definida pelo usuário.
Restrições na especialização e generalização

Duas restrições devem ser consideradas na especialização:
1) Restrição de disjunção: especifica que as subclasses da especialização devem ser mu-
tuamente exclusivas, ou seja, uma entidade pode pertencer a somente uma subclasse
da especialização. Este é o caso do nosso exemplo: um aluno é, obrigatoriamente, alu-
no de graduação ou de pós-graduação. O círculo com a letra d (do inglês disjointness)
dentro especifica essa situação.
Contrária a essa situação, temos que uma entidade pode pertencer a mais de uma
subclasse ao mesmo tempo. Nesse caso, dizemos que há uma sobreposição, ou seja,
uma mesma entidade pode pertencer a mais de uma subclasse da especialização.
Seria o caso de um aluno fazer pós-graduação e uma graduação em outra área, ao
mesmo tempo. A representação é feita por um círculo com a letra o dentro (overlap).
Se uma superclasse tiver apenas uma subclasse, não há necessidade de colocar o cír-
culo com a letra dentro, pois, nesse caso, nunca haverá disjunção ou sobreposição.
2) Restrição de integralidade: pode ser total ou parcial. Será total quando toda entidade
de uma superclasse pertencer a, pelo menos, uma das subclasses dessa superclasse;
neste caso, é representada por um traço duplo. A restrição será parcial quando uma
entidade da superclasse não pertencer a nenhuma das subclasses definidas; é repre-
sentada por um traço simples.

Há quatro possibilidades de restrições, considerando-se que os dois tipos (total e par-

cial) de restrições são independentes:
a) Disjunção total.
b) Disjunção parcial.
c) Sobreposição total.
d) Sobreposição parcial.

unidade:
1) Quais são as fases constituintes de um projeto de banco de dados?
2) Defina e exemplifique os seguintes conceitos:

a) Entidade.
b) Relacionamento.
c) Atributo.
d) Cardinalidade.
3) Além de relacionamentos e atributos, propriedades podem ser atribuídas a entidades fazendo-se uso do concei-
to de generalização/especialização. Dê pelo menos três exemplos de entidade genérica e especializada.
4) O que é uma entidade associativa? Exemplifique.
5) Quais são os principais tipos de atributos? Cite pelo menos um exemplo de cada.
6) Escolha a opção que representa corretamente, no Modelo Entidade-Relacionamento, a afirmação: Todo jogador
deve pertencer a um único clube.
a)
Figura 27 Modelo Entidade-Relacionamento I.
b)
Figura 28 Modelo Entidade-Relacionamento II.
c)
Figura 29 Modelo Entidade-Relacionamento III.
d)
Figura 30 Modelo Entidade-Relacionamento IV.

e)
Figura 31 Modelo Entidade-Relacionamento V.
7) Considere o Modelo Entidade-Relacionamento (Figura 32), em que o relacionamento Ocupa indica o Cargo que
o Empregado ocupa atualmente, e o relacionamento Ocupado indica os cargos anteriormente ocupados pelo
empregado, se houver. Para cada afirmação a seguir, assinale V (verdadeira) ou F (falsa).
(0,N) (1,1)
Ocupa
Empregado Cargo
Ocupado
(0,N) (0,N)
Figura 32 Modelo Entidade-Relacionamento Empregado -
Cargo.
O modelo está incorreto porque não pode haver 2 relacionamentos entre as mesmas entidades;
Pode haver um Empregado que não ocupa um Cargo;
Para que o modelo contenha a data em que um Empregado deixou de ocupar um Cargo essa data deve ser
colocada como atributo do relacionamento Ocupado;
O relacionamento Ocupado permite identificar todos os cargos que um Empregado já ocupou, menos o cargo
que ocupa atualmente;
Todo Cargo tem pelo menos um Empregado que o ocupa;
8) Constitua a modelagem das especificações mencionadas a seguir utilizando o MER, juntamente às suas respec-
tivas cardinalidades. (Observação: defina os atributos que julgar necessário).
a) Administradora de Imóveis:
Uma entrevista com o gerente da administradora resultou nas seguintes informações:
I. A administradora administra condomínios formados por unidades condominiais (lotes).
II. Cada unidade condominial é de propriedade de uma ou mais pessoas. Uma pessoa pode possuir diversas
unidades.
III. Cada unidade pode estar alugada para, no máximo, uma pessoa. Uma pessoa pode alugar diversas uni-
dades.
b) Clínica:
I. Em uma clínica trabalham médicos e existem pacientes internados.
II. Cada médico é identificado pelo seu CRM, possui um nome e recebe um salário na clínica.
III. Um médico tem formação em diversas especialidades (ortopedia, traumatologia etc), entretanto, só
exerce uma delas na clínica.
IV. Para todo paciente internado na clínica são cadastrados alguns dados pessoais: nome, RG, CPF, endere-
ço, telefone(s) para contato e data de nascimento.
V. Um paciente tem sempre um determinado médico como responsável (com horário de visita diária pre-
determinado), porém, vários outros médicos podem participar do seu tratamento.
VI. Pacientes estão sempre internados em quartos individuais, que são identificados por um número e ficam
em um andar da clínica.
c) Biblioteca:
I. Uma biblioteca mantém um conjunto de livros, de diversas categorias.
II. Conforme as suas categorias, eles estão dispostos em estantes apropriadas.
III. Um livro tem vários exemplares na biblioteca.
IV. São mantidos dados detalhados sobre autores e editoras dos livros para fins de consulta.
V. Na biblioteca trabalham várias bibliotecárias.
VI. Cada bibliotecária é responsável por organizar periodicamente sempre o mesmo conjunto de estantes e
realizar empréstimos de exemplares para os clientes.
VII. Empréstimos cadastrados no banco de dados devem conter a data da devolução e o valor diário da mul-
ta, permanecendo no banco de dados até o cliente realizar a entrega do exemplar.
VIII. O nome da bibliotecária que realizou o empréstimo também deve ser mantido no banco de dados.

IX. Algumas bibliotecárias são estagiárias.

X. Uma bibliotecária estagiária está sempre sob a responsabilidade de uma bibliotecária efetiva.
XI. Deve-se saber também a instituição de ensino de onde vem a estagiária.
Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
6) c.
7)
F.
F.
V.
V.
F.
13. CONSIDERAÇÕES
O modelo entidade-relacionamento apresentado nesta unidade é utilizado pelos projetis-
tas de bancos de dados na fase do projeto conceitual, pois é um modelo de dados de alto nível.
Os conceitos do modelo entidade-relacionamento foram apresentados e demonstrados
por meio de um exemplo de aplicação específica simplificada para uma escola, com o objetivo
de facilitar a sua explanação e demonstrar que o modelo conceitual depende das regras e restri-
ções definidas pelos analistas de negócios.
O projeto lógico necessita da adoção de um modelo de dados lógico específico, e o mo-
delo adotado neste estudo é o modelo relacional, devido a sua larga utilização no mercado. O
modelo relacional será o assunto estudado na próxima unidade.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4. ed. Porto Alegre: Sagra Luzzatto, 2001.
RAMAKRISHNAN, R; GEHRKE, J. Database Management Systems. 2. ed. Boston: McGraw-Hill, 2000.
ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementação e Administração. São Paulo: Cengage Learning, 2011.
Modelo de Dados Relacional
1. OBJETIVO
• Construir o conhecimento básico necessário para o desenvolvimento de um projeto
lógico de Banco de Dados Relacional baseado no Modelo Conceitual.
2. CONTEÚDOS
• Modelo Relacional.
• Notação do Modelo Relacional.
• Atributos-chave de uma relação.
• Esquema de Banco de Dados Relacional.
• Restrições de integridade sobre relações.
• Projeto lógico de banco de dados: Entidade-Relacionamento para Relacional.

guir:
1) Lembre-se de que sua participação é fundamental para a construção do conhecimen-
to. Discuta com seus colegas e tutor sobre diferentes situações a fim de conhecer a
realidade das salas de aula.
2) Realize as interatividades e atividades propostas. Participe! Interaja com seus colegas

de curso e com seu tutor. Lembre-se de que é fundamental que você entregue as ati-
vidades nas datas previstas.
3) Fique atento a todo o conteúdo desta unidade, no qual você encontrará conceitos
importantes para sua aprendizagem, como: modelo relacional, notação do modelo re-
lacional, atributos-chave de uma relação, esquema de banco de dados relacional etc.
4) Se necessário, retorne às unidades anteriores para entender e recordar os conceitos
propostos. Consulte sempre o Glossário de conceitos-chave quando surgirem ideias
que ainda não foram completamente abstraídas.
5) Entender álgebra relacional é importante para que você compreenda adequadamente
o modelo relacional (E. F. Codd – 1970), o qual é baseado na lógica dos predicados e
na teoria dos conjuntos.
Na unidade anterior, você teve a oportunidade de estudar o modelo entidade-relaciona-
mento (MER) e conhecer o que é entidade, atributos e conjuntos de entidades. Também pôde
aprender como é a estrutura do diagrama entidade-relacionamento e como formular um proje-
to conceitual de banco de dados utilizando o MER.
Nesta unidade, você estudará o projeto lógico de um banco de dados relacional, cuja base
é o modelo conceitual.
5. MODELO RELACIONAL
O modelo relacional, baseado na lógica dos predicados e na teoria dos conjuntos, foi apre-
sentado por E. F. Codd em 1970 e representa os dados contidos em um banco de dados por meio
de relações (tabelas).
A lógica dos predicados, amplamente utilizada pela matemática, fornece um modelo em
que uma proposição (afirmação de um fato) pode ser verificada como verdadeira ou falsa. Por
exemplo, suponha que uma estudante com ID 12345678 se chame Melissa Mendes. Essa pro-
posição pode ser facilmente demonstrada como verdadeira ou falsa.
A teoria dos conjuntos é a parte da ciência matemática que lida com conjuntos (grupos
de coisas), sendo utilizada como base para a manipulação de dados no modelo relacional. Por
exemplo, suponha que o conjunto A contenha três números: 16, 24 e 77. Esse conjunto é repre-
sentado por A(16, 24, 77). O conjunto B, por sua vez, contém quatro números: 44, 77, 90 e 11,
sendo, portanto, representado por B(44, 77, 90, 11). Com base nessas informações, é possível
concluir que a intersecção de A e B dará origem a um terceiro conjunto, formado apenas pelo
número 77. Esse resultado pode ser expresso por A ∩ B = 77. Em outras palavras, A e B com-
partilham um valor comum, 77.
Segundo Alvarenga (2012):
O Modelo Relacional é claramente baseado no conceito de matrizes, onde as chamadas linhas (das
matrizes) seriam os registros e as colunas (das matrizes) os campos. Os nomes das tabelas e dos cam-
pos são de fundamental importância para sua compreensão entre o que estamos armazenando, onde
estamos armazenando e qual a relação existente entre os dados armazenados.
Para esclarecer melhor essa questão, observe os nomes na Tabela 1, na qual serão feitas
as comparações necessárias. Você pode notar que os nomes são diferentes para cada área de
atuação, mas têm o mesmo significado em cada uma delas.
© U3 – Modelo de Dados Relacional 77
Tabela 1 Comparações e convenções em banco de dados.

INFORMÁTICA TRADICIONAL BASE DE DADOS RELACIONAL ÁLGEBRA RELACIONAL
Arquivo Tabela Relação
Registro Linha Tupla
Campo Coluna Atributo
Existem algumas convenções importantes para a utilização dos nomes, quer para as tabe-
las, quer para os atributos que as constituem. Uma convenção não tem sentido obrigatório, no
entanto deve ser respeitada para evitar incompatibilidades ou erros.
Determinados SGBD, como, por exemplo, o Microsoft Access, permitem alguma flexibili-
dade com os nomes das tabelas e os nomes dos atributos, ao contrário de outros. Essa flexibili-
dade pode trazer pequenos problemas quando pretendemos realizar a migração de um SGBD em
MySQL ou Access, por exemplo, para um SGBD em Oracle.
Os SGBDs que utilizam o modelo relacional são denominados SGBD Relacionais. Algumas
convenções devem ser seguidas em um modelo relacional. Por exemplo, os nomes das tabelas
deverão ter por base as entidades que representam. É necessário que o nome de cada tabela
seja único, ou seja, não deve haver duplicação de nomes de tabelas dentro da mesma base de
dados.
Existem diferentes convenções quanto à singularidade ou pluralidade dos nomes das ta-
belas. Não importa a convenção adotada, mas é importante manter a coerência do método ado-
tado em todas as tabelas; isto é, se a opção for um nome no singular, devem-se utilizar nomes
no singular em todas as tabelas e vice-versa.
Por convenção, para os nomes, devemos utilizar unicamente letras minúsculas e o unders-
core ( _ ) para separar palavras. Underscore também é conhecido como underline.
Devemos usar abreviaturas quando necessário, por exemplo, para diminuir os nomes que
atinjam o número máximo de caracteres permitidos pelo SGBD.
Os nomes dos campos devem basear-se no nome do atributo definido no desenho lógico,
os quais devem ser únicos dentro da tabela; é necessário atenção, pois alguns SGBDs podem ser
sensíveis ao fato de o nome do campo estar escrito em maiúsculas e/ou minúsculas.
Para que você entenda alguns nomes utilizados em uma relação, veja a Figura 1. Cada
linha da relação será chamada de tupla, e cada coluna da relação será chamada de atributo. O
conjunto de valores passíveis de serem assumidos por um atributo será intitulado de domínio.
nome da relação atributos
ALUNO NumMec Nome Curso

798764544 João Pinto CC
345673451 Carlos Semedo ERSI
tuplas
relação 487563546 Maria Silva EG
452212348 Pedro Costa MAT
Figura 1 Exemplo da Relação ALUNO.

O esquema de uma relação nada mais são que as colunas existentes em uma tabela. Já
a instância da relação consiste no conjunto de valores que cada atributo assume em um de-
terminado instante. Portanto, os dados armazenados no banco de dados são formados pelas
instâncias das relações.
Uma relação esquema R, dada por R(A1, A2, A3, ..., An), é um conjunto de atributos de R: {A1,
A2, A3, ..., An }. Cada atributo Ai possui um domínio D(Ai). O grau de uma relação é definido como
o número de atributos que ele contém.
Observando a Figura 1, podemos dizer que:
1) ALUNO (NumMec, Nome, Curso) é a relação esquema.
2) ALUNO é o nome da relação.
3) O grau da relação é 3.
4) Os domínios dos atributos são:
a) D(NumMec): números que representam o código dos alunos.
b) D(Nome): caracteres compostos de letras que formam o nome dos alunos.
c) D(Curso): caracteres que representam a sigla da disciplina.
É necessário destacar que as relações não podem ser duplicadas (não podem existir dois
códigos idênticos de alunos no conjunto de Código de Alunos), e a ordem de entrada de dados
no banco de dados não deverá ter qualquer importância para as relações, no que concerne ao
seu tratamento. Os atributos deverão ser atômicos, isto é, indivisíveis.
Tabela
A perspectiva lógica do banco de dados relacional é facilitada pela criação de relaciona-
mento de dados com base em uma estrutura conhecida como relação. Como a relação é uma
estrutura matemática, os usuários finais consideram mais fácil pensar na relação como uma
tabela, vista como uma estrutura bidimensional composta de linhas e colunas. Ela é chamada
de relação, pois o criador do modelo relacional, E. F. Codd, utilizou esse termo como sinônimo
de tabela.
Uma tabela pode conter um grupo de ocorrências de entidades relacionadas, ou seja, um
conjunto de entidades. Por exemplo, uma tabela ALUNO contém um conjunto de ocorrências de
entidades, cada uma representando um aluno.
As tabelas possuem várias características que devem ser compreendidas. Veja algumas
destas características na Tabela 2:
Tabela 2 Características de uma tabela.

ITEM CARACTERÍSTICA
1 A tabela deve ser entendida como uma estrutura bidimensional composta de linhas e colunas.
2 Cada linha (tupla) representa uma única ocorrência de entidade no interior do conjunto de entidades.
3 Cada coluna da tabela representa um atributo e deve possuir um nome diferente.
4 Cada intersecção entre linha e coluna representa um único valor.
5 Todos os valores em uma coluna devem ser de um mesmo formato (número, data).
6 Cada coluna possui uma faixa específica de valores conhecida como domínio de atributos.
7 A ordem das linhas e das colunas é insignificante para o SGBD.
Cada tabela deve apresentar um atributo ou uma combinação deles que identifique o registro de forma exclusiva
8
(CPF, por exemplo).
A tabela representada pela Figura 2 apresenta uma exemplificação que aborda as caracte-
rísticas listadas na Tabela 2.
Figura 2 Exemplo de Tabela.
A Figura 2 demonstra um exemplo de tabela para cadastro de ALUNOS, em que cada co-
luna representa:
STU_NUM: Número do aluno.
STU_LNAME: Sobrenome do aluno.
STU_FNAME: Primeiro nome do aluno.
STU_CLASS: Classificação do aluno.
STU_DOB: Data de nascimento do aluno.
STU_GPA: Média das notas.
STU_HRS: Créditos-hora obtidos.
STU_INIT: Letra inicial do nome do meio do aluno.
STU_PHONE: Extensão de quatro dígitos do telefone do campus.
STU_TRANSFER: Aluno que foi transferido de outra instituição.
DEPT_CODE: Código do departamento.
PROF_NUM: Número do professor que é o orientador do aluno.
De acordo com os itens enumerados na Tabela 2, e utilizando a tabela ALUNO apresentada
na Figura 2, podemos concluir que:
1) A tabela ALUNO é vista como uma estrutura bidimensional composta de sete linhas
(tuplas) e doze colunas (atributos).

2) Cada linha da tabela ALUNO descreve uma única ocorrência de entidade no interior
do conjunto de entidades (esse conjunto é representado por toda a tabela ALUNO).
Observe que a linha (entidade ou registro) definida por STU_NUM = 324561 define as
características (atributos ou campos) de um aluno chamado João C. Silva. Já a Linha 4
da Figura 2, por exemplo, descreve um aluno chamado Walter H. Ortolani; de modo si-
milar, a Linha 3 descreve uma aluna chamada Juliana Bravo. Dado o conteúdo da tabe-
la, o conjunto de entidade ALUNO inclui sete entidades (linhas) ou alunos diferentes.
3) Cada coluna representa um atributo e possui um nome diferente. Conforme pode ser
observado, não se verifica nenhuma coluna cujo nome seja repetido.
4) Todos os valores de uma coluna atendem às características do atributo. Por exemplo,
a coluna média das notas (STU_GPA) contém apenas entradas de STU_GPA em todas
as linhas da tabela, ou seja, todas as entradas são relativas unicamente à média. Os
dados devem ser classificados de acordo com seu formato e função.
Embora diferentes SGBDs possam dar suporte a diferentes tipos de dados, a maioria
aceita, pelo menos, os seguintes dados:
a) Numéricos: são aqueles com os quais é possível executar procedimentos aritméti-
cos com significado. Por exemplo, as colunas STU_HRS e STU_GPA da Figura 2 são
atributos numéricos. Por outro lado, STU_PHONE não é um atributo numérico,
pois a adição ou subtração de números telefônicos não produz um resultado arit-
meticamente significativo.
b) Caracteres: conhecidos como dados de texto ou de string, podem conter quais-
quer caracteres ou símbolos não destinados à manipulação matemática. Na Figu-
ra 2, por exemplo, as colunas STU_LNAME, STU_FNAME, STU_INIT, STU_CLASS e
STU_PHONE são atributos de caracteres.
c) Data: contêm datas de calendário armazenadas em um formato especial. Embora
o armazenamento físico da data seja insignificante para o usuário ou o projetis-
ta, esse formato permite a execução de um tipo especial de aritmética conheci-
do como aritmética das datas. Utilizando-a, é possível determinar o número de
dias que se passaram entre duas datas, como 12 de maio de 1999 e 20 de março
de 2008, simplesmente subtraindo a primeira da segunda. Na Figura 2, a coluna
STU_DOB pode ser classificada adequadamente como um atributo do tipo data. A
maioria dos SGBDs relacionais permite a personalização do formato de apresen-
tação de dados. Por exemplo, os usuários de Oracle podem especificar o formato
"dd/mmm/aaaa" para mostrar o primeiro valor de STU_DOB na Figura 2 como 12/
Fev/1975 (ao examinar os valores dessa coluna, você pode ver que esse formato
foi selecionado para a apresentação da saída).
d) Lógicos: dados lógicos podem ser apenas uma condição verdadeira ou falsa (sim
ou não). Por exemplo, um aluno é terceiro anista transferido? Na Figura 2, o atri-
buto STU_TRANSFER utiliza o formato de dados lógico, que também é conhecido
como booleano. A maioria dos pacotes de software de bancos de dados relacio-
nais suporta esse formato.
5) A faixa de valores permitidos para a coluna é conhecida como domínio. Os valores de
STU_GPA estão limitados na faixa 0-4, inclusive o domínio [0,4].
6) A ordem das linhas e das colunas é insignificante para o usuário.
7) Cada tabela deve ter uma chave primária. Em termos gerais, a chave primária (PK, do
inglês Primary Key) é um atributo (ou uma combinação de atributos) que identifica
exclusivamente uma determinada linha. Nesse caso, STU_NUM (o número do aluno) é
a chave primária. Utilizando os dados representados na Figura 2, observe que o sobre-
nome de um aluno (STU_LNAME) não seria uma boa chave primária, pois é possível
encontrar vários alunos com o sobrenome Smith, por exemplo. Mesmo a combinação
de nome (STU_FNAME) e sobrenome não constituiria uma chave primária adequada,
pois também é possível encontrar mais de um aluno chamado João Silva.
6. NOTAÇÃO DO MODELO RELACIONAL

Algumas notações e conceitos devem ser considerados para apresentar o modelo relacio-
nal. Veja-os a seguir:
Relação
1) Conjunto não ordenado de tuplas.
2) Corresponde a entidades-tipo ou relacionamentos da base de dados.
3) É definida por esquemas do tipo R(A1, A2, A3, ..., An), em que R é o nome da relação, e
A1, A2, A3, ..., An é a lista de atributos.
4) Corresponde a uma tabela de valores.
Atributo
1) Identifica uma característica/propriedade de uma relação.
Exemplo:
R.Ai representa o atributo Ai da relação R.
Domínio
1) Conjunto de valores atômicos que caracterizam um atributo.
Exemplo:
D(Ai) representa o domínio do atributo Ai.
Tuplas
1) Sequência ordenada de valores.
2) Todas as tuplas de uma relação são diferentes, pois representam entidades ou relacio-
namentos específicos da base de dados.
3) São definidas por sequência do tipo <v1, v2, v3, ..., vi>, em que cada vi corresponde ao
valor da tupla para o atributo Ai ou valor null.
a) vi Є D(Ai) ou vi = NULL. Lê-se: vi, 1<= i <= n, ou é nulo ou pertence ao domínio D(Ai).
Figura 3 Tuplas.

b) t[Ai] ou t[i] representa o valor da tupla para o atributo Ai.

4) Os nomes de atributos são, algumas vezes, qualificados com o nome da relação à qual
pertencem, por exemplo: ALUNO.Nome ou ALUNO.Curso.
Exemplo:
• Considere a tupla t= <798764544, João Pinto, CC> da relação ALUNO da Figura 1.
Temos que:
• t[NumMec] = 798764544 e t[Nome,Curso]=<João Pinto, CC>.
7. ATRIBUTOS-CHAVE DE UMA RELAÇÃO

Até o momento, você estudou vários conceitos importantes sobre o modelo de dados
relacional. Neste tópico, iniciaremos o estudo de mais um conceito essencial para o seu apren-
dizado, que são os atributos-chave de uma relação. Fique atento!
No modelo relacional as chaves são importantes, pois sua utilização garante que cada
linha da tabela seja identificável de modo exclusivo, facilitando buscas posteriores, além de
assegurar a consistência e integridade dos dados. Elas também são utilizadas para estabelecer
relacionamentos entre tabelas.
Para cada relação, deve existir uma chave, que vai ser constituída por um atributo ou um
conjunto de atributos e que identifica cada tupla (ou instância da relação) de um modo único,
pois essa chave permite que seja estabelecido um relacionamento com outras tabelas.
É importante lembrar que não podem existir duas tuplas com os mesmos dados para o
mesmo atributo ou conjunto de atributos.
O papel da chave baseia-se em um conceito conhecido como determinação. No contexto
de tabela de bancos de dados, a afirmação "A determina B" indica que conhecer o valor do atri-
buto A possibilita verificar (determinar) o valor de B. Por exemplo, conhecer apenas o identifi-
cador de um registro, como no exemplo da tabela ALUNO (Figura 2) – o STU_NUM –, é bastante
útil, pois, a partir dele, torna-se possível obter (determinar) qualquer informação pertinente ao
aluno cujo STU_NUM se faz conhecido: o sobrenome, a média das notas, o número de telefo-
ne, entre outros. A notação abreviada para "A determina B" é A à B. Se A determina B, C e D,
escreve-se AàB, C, D. Portanto, utilizando os atributos da tabela ALUNO da Figura 2, é possível
representar a afirmação "STU_NUM determina STU_LNAME", escrevendo:
STU_NUMSTU_LNAME
De fato, o valor STU_NUM da tabela ALUNO determina todos os valores de atributos do

aluno. Por exemplo, é possível escrever:
STU_NUMSTU_LNAME, STU_FNAME, STU_INIT

e
STU_NUMSTU_LNAME, STU_FNAME, STU_INIT, STU_DOB, STU_TRANSFER
Fica claro que uma vez conhecido o identificador de um registro de uma tabela, é possível
identificar, a partir dele, quaisquer atributos pertinentes a esse registro. Deste modo, conhecen-
do-se STU_NUM, podemos determinar qualquer atributo pertencente a um aluno; em contra-
partida, não é possível conhecer STU_NUM a partir de STU_LNAME, pois é possível que vários
alunos tenham o mesmo sobrenome (por exemplo, Silva).
O princípio de determinação é importante, pois é utilizado na definição de um conceito

central de bancos de dados relacionais, conhecido como dependência funcional, o qual pode
ser definido da seguinte maneira: o atributo B é funcionalmente dependente de A se A determi-
na B. Mais precisamente: o atributo B é funcionalmente dependente do atributo A se cada valor
da coluna A determina um (e somente um) valor da coluna B.
Quando uma chave é composta apenas por um atributo, podemos dizer que se trata de
uma chave simples. No exemplo da Tabela ALUNO, demonstrada na Figura 2, observa-se a exis-
tência de apenas uma chave. Uma chave constituída por mais de um atributo é denominada
chave composta.
Para entender melhor o que são as chaves e como funcionam no modelo relacional, é
necessário compreender alguns conceitos, tais como: chave candidata, chave primária e chave
estrangeira. Observe suas definições a seguir:
Chave candidata é todo atributo ou conjuntos de atributos que permite identificar, de
modo único, cada tupla. No entanto, para proceder a esta seleção de chaves candidatas, é ne-
cessário conhecer bem a realidade de cada um dos atributos da relação e qual o seu domínio.
Dentre todas as chaves candidatas, apenas uma será escolhida para identificar cada tupla
de forma única. A chave selecionada dentre as chaves candidatas é designada chave primária
da relação. Em todas as tabelas deve existir sempre uma chave primária, e os atributos que a
constituem não podem conter valores nulos.
Uma chave candidata pode ser descrita como uma superchave sem atributos desnecessá-
rios, ou seja, uma superchave mínima.
A superchave é qualquer chave que identifique cada linha exclusivamente. Em resumo,
ela determina funcionalmente todos os atributos de uma linha. Na tabela ALUNO, a superchave
poderia ser qualquer uma das seguintes colunas:
STU_NUM
STU_NUM, STU_LNAME
STU_NUM, STU_LNAME, STU_INIT
De fato, STU_NUM, com ou sem valores adicionais, pode ser uma superchave, mesmo
quando os atributos adicionais são redundantes.
Tomando como exemplo a chave composta STU_NUM, STU_LNAME, pode-se dizer que
esta é uma superchave, mas não uma chave candidata. Para que esta chave pudesse ser uma
chave candidata, teríamos que nos assegurar que não haveria nenhum sobrenome de aluno em
duplicidade na tabela ALUNO.
Portanto, a chave primária é a chave candidata escolhida para construir o identificador
exclusivo da linha. Podemos afirmar que uma chave primária é tanto uma superchave como uma
chave candidata.
A chave primária possui algumas características, tais como:
• Ser unívoca: os atributos definidos para ser chave primária, por definição, devem ter
valor único para cada registro ou tupla na relação, de modo a garantir que todas as
linhas sejam identificadas exclusivamente por essa chave. Nesse caso, diz-se que a ta-
bela apresenta integridade de entidade.

• Não nula: nenhum dos atributos que formam uma chave primária poderá conter um
valor nulo em um registro.
• Não redundante: no caso de uma chave primária ser composta, não devem ser incluí-
dos mais atributos do que os mínimos necessários para identificar os registros de modo
unívoco.
Chave estrangeira (forasteira ou externa) é todo atributo ou conjunto de atributos que é a
chave primária em outra tabela, ou seja, quando um atributo surge em mais do que uma tabela,
estamos perante um relacionamento de tuplas.
A redundância controlada faz com que o banco de dados relacional funcione. As tabelas
no banco de dados compartilham atributos comuns que permitem sua ligação. Por exemplo, ob-
serve que as tabelas PRODUTO e FORNECEDOR na Figura 4 compartilham um atributo comum
chamado VEND_CODE. Note também que o VEND_CODE com valor 232 na tabela PRODUTO
ocorre mais de uma vez, assim como o 235.
Como a tabela PRODUTO está relacionada a FORNECEDOR por meio desses valores VEND_
CODE, sua ocorrência múltipla é necessária para fazer com que o relacionamento 1:M entre
FORNECEDOR e PRODUTO funcione. Cada valor VEND_CODE da tabela FORNECEDOR é exclu-
sivo, e o FORNECEDOR é o lado 1 do relacionamento FORNECEDOR-PRODUTO. Mas qualquer
valor VEND_CODE da tabela FORNECEDOR pode ocorrer mais de uma vez na tabela PRODUTO,
evidenciando que PRODUTO é o lado M desse relacionamento. Em termos de bancos de dados,
as múltiplas ocorrências dos valores VEND_CODE na tabela PRODUTO não são redundantes,
pois são necessárias para que o relacionamento funcione.
Figura 4 Exemplo de um banco de dados relacional simples.

Na Figura 4, observe que o valor VEND_CODE em uma tabela pode ser utilizado para in-
dicar o valor correspondente em outra tabela. Desta forma, além de manter-se a integridade
dos dados, evitamos repetições desnecessárias. Por exemplo, o valor VEND_CODE 235 na ta-
bela PRODUTO indica o fornecedor Henry Ortozo da tabela FORNECEDOR. Consequentemente,
descobre-se que o produto Houselite chain saw, 16-in bar (motosserra Houselite com barra de
16 polegadas) é fornecido por Henry Ortozo, o qual pode ser contatado pelo número 615-123-
5529. A mesma relação pode ser feita para o produto Steel tape, 12-ft legth (fita de aço com 12
pés de comprimento) da tabela PRODUTO.
8. ESQUEMA DE BANCO DE DADOS RELACIONAL

No tópico anterior, você pôde observar um esquema de relação e uma relação associada.
Agora, você conhecerá um sistema de banco de dados relacional e perceberá que ele contém,
normalmente, várias relações em que as tuplas relacionam-se de diversas maneiras.
Um esquema de banco de dados relacional S é um conjunto de esquemas de relação S=
{R1, R2, ..., Rm} e um conjunto RI de restrições de integridade. Já um banco de dados relacional
BD de S é um conjunto de relações BD={r1, r2, ..., rm}, tal que cada ri é uma relação associada ao
esquema Ri e satisfaz as restrições de integridade em RI.
No próximo tópico desta unidade, você verá mais detalhes sobre restrições de integridade.
Um esquema relacional é uma representação textual das tabelas de bancos de dados em
que cada tabela PE relacionada com seu nome é seguida pela lista de seus atributos entre pa-
rênteses. O(s) atributo(s) de chave primária deve(m) aparecer sublinhado(s). Por exemplo, o
esquema relacional para a Figura 4 seria representado como:
FORNECEDOR (VEND_CODE, VEND_CONTACT, VEND_AREACODE, VEND_PHONE)
PRODUTO (PROD_CODE, PROD_DESCRIPT, PROD_PRICE, PROD_ON_HAND, VEND_CODE)
A ligação entre as tabelas PRODUTO e FORNECEDOR da Figura 4 também pode ser repre-
sentada pelo diagrama relacional exibido na Figura 5. Nesse caso, a ligação é indicada pela linha
que conecta as tabelas.
Figura 5 Diagrama relacional.
Observe que a ligação na Figura 5 é equivalente à reta de relacionamento de um DER.

Ela é criada quando duas tabelas compartilham um atributo com valores comuns. Mais especi-
ficamente, a chave primária de uma tabela (FORNECEDOR) aparece como a chave estrangeira

de uma tabela relacionada (PRODUTO). Uma chave estrangeira FK (do inglês Foreign Key) é um
atributo cujos valores correspondem aos da chave primária na tabela relacionada. Por exemplo,
na Figura 5, VEND_CODE é a chave primária da tabela FORNECEDOR e aparece como chave es-
trangeira da tabela PRODUTO.
Se a chave estrangeira contém valores correspondentes ou nulos, diz-se que a tabela que
contém essa chave apresenta integridade referencial. Em outras palavras, integridade referen-
cial significa que se a chave estrangeira contém um valor, esse valor se refere a uma tupla (linha)
válida existente em outra relação.
9. RESTRIÇÕES DE INTEGRIDADE SOBRE RELAÇÕES

As restrições de integridades mencionadas anteriormente correspondem às regras as
quais toda relação de uma base de dados (relacional) deve obedecer. Tais regras são muito
importantes para um projeto de bancos de dados e são aplicadas automaticamente por muitos
SGBDs.
Existem várias restrições que podem ser especificadas no modelo de dados relacional,
conforme demonstra a Tabela 3:
Tabela 3 Regras de integridade.

INTEGRIDADE DE ENTIDADES DESCRIÇÃO
Todas as entradas de chave primária são únicas e nenhuma parte dessa chave pode ser
Exigência
nula.
Cada linha terá uma identidade exclusiva, e valores de chave estrangeira podem
Finalidade
referenciar de modo adequado os valores de chave primária.
Nenhum vendedor pode ter número duplicado nem ser nulo. Portanto, todos os
Exemplo
vendedores são identificados de modo exclusivo por seu número.
INTEGRIDADE REFERENCIAL DESCRIÇÃO
Uma chave estrangeira pode ter uma entrada nula, contanto que não faça parte de
uma chave primária de suas tabelas, ou uma entrada que coincida com o valor de chave
Exigência
primária de uma tabela que esteja relacionada (todo valor não nulo de chave estrangeira
deve referenciar um valor de chave primária existente).
É possível que um atributo não tenha valor correspondente, mas é impossível que tenha
uma entrada inválida. A aplicação da regra de integridade referencial torna impossível a
Finalidade
exclusão de uma linha de uma tabela cuja chave primária tenha valores obrigatórios de
chave estrangeira em outra tabela.
Um cliente pode ainda não ter recebido a atribuição de um representante de vendas
Exemplo
(número), mas é impossível que tenha um representante de vendas inválido (número).
Uma definição formal da restrição de integridade referencial exige a definição de Chave

Estrangeira (CE). Um conjunto de tributos CE em um esquema de relação R1 é uma chave es-
trangeira que referencia um esquema de relação R2 se ele satisfaz as seguintes propriedades:
• Os atributos de CE possuem o mesmo domínio dos atributos da Chave Primária (CP) da
outra relação de esquema R2. Diz-se que os atributos em CE referenciam ou referem-se
a R2.
• Uma CE na Tupla t1 de r(R1) ou tem um valor que ocorre como CP de alguma Tupla t2
de r(R2) ou tem o valor nulo. No primeiro caso, tem-se t1[CE] = t2[CP] e diz-se que t1
referencia ou refere-se a t2.
Normalmente, as restrições de integridade referencial derivam-se dos relacionamentos
entre conjuntos de entidades representadas pelos esquemas de relação.
Outras regras de integridade que podem ser aplicadas no modelo relacional são as restri-
ções not null e unique. A restrição not null pode ser aplicada a uma coluna para garantir que
todas as linhas da tabela apresentem um valor para essa coluna, enquanto a restrição unique é
aplicada a uma coluna para garantir que não haja nenhum valor duplicado.
10. OPERADORES DO CONJUNTO RELACIONAL

As operações da Álgebra Relacional são utilizadas para selecionar tuplas de uma deter-
minada relação ou para combinar tuplas relacionadas a diversas relações, com o propósito de
especificar uma consulta (uma requisição de recuperação) sobre a base de dados.
A Álgebra Relacional é uma coleção de operadores que tomam relações com seus ope-
randos e retornam uma relação como resultado. Desta forma, por meio de seus operadores
específicos e adequados, é possível fazer a combinação de tuplas, relacionadas ou não, e obter
a resultante desejada.
A Álgebra Relacional é uma linguagem teórica que trabalha com operações que conte-
nham uma ou mais relações, a partir das quais outra relação é criada de modo a não alterar
a relação originária. É importante mencionar que a Álgebra Relacional é uma linguagem abs-
trata, o que significa que as queries formuladas por ela não são destinadas à execução em
um computador; portanto, o uso desta linguagem permite a compreensão da execução das
queries no banco de dados. Somam oito os operadores relacionais: Union, Intersect, Diference,
Product, Select, Project, Join e Divide.
Union
Este operador combina todas as linhas de duas tabelas, excluindo as duplicadas. As tabelas
devem apresentar as mesmas características de atributos (as colunas e os domínios devem ser
idênticos) para serem utilizadas no operador union. Um exemplo da utilização do union é apre-
sentado na Figura 6:
P_CODE P_DESCRIPT PRICE P_CODE P_DESCRIPT PRICE
123456 Flashlight 5.26 345678 Mocrowave 160.00

UNION
123457 Lamp 25.15 345679 Dishwasher 500.00
123458 Box Fan 10.99
123459 9v Battery 1.99 resulta em
123460 Powerdrill 34.99
P_CODE P_DESCRIPT PRICE

123456 Flashlight 5.26
123457 Lamp 25.15
123458 Box Fan 10.99
123459 9v Battery 1.99
123460 Powerdrill 34.99
345678 Mocrowave 160.00
345679 Dishwasher 500.00
Figura 6 Union.

Intersect
O operador intersect resulta apenas em linhas que aparecem em ambas as tabelas. Assim
como no union, só se produzirão resultados se as tabelas forem compatíveis para união. Por
exemplo, não é possível utilizar intersect se um dos atributos for numérico e o outro for baseado
em caracteres. Veja o efeito do intersect apresentado na Figura 7.
F-NAME F-NAME F-NAME

George Jane resulta em
INTERSECT Jane
Jane William Jorge
Elaine Jorge
Wilfred Dennis
Jorge
Figura 7 Intersect.
Difference
O resultado deste operador será todas as linhas de uma tabela que não se encontram na
outra tabela, ou seja, uma tabela é subtraída da outra. Como no caso do union, só se produ-
zirão resultados válidos se as tabelas forem compatíveis para união. O efeito do difference é
apresentado na Figura 8. No entanto, observe que subtrair a primeira tabela da segunda não
é igual a subtrair a segunda da primeira.
F-NAME F-NAME
George Jane F-NAME
resulta em
Jane William George
DIFFERENCE
Elaine Jorge Elaiine
Wilfred Dennis Wilfred
Jorge
Figura 8 Difference.
Product
Resultará em todos os pares de linhas possíveis a partir de duas tabelas. Essa operação
também é conhecida como produto cartesiano. Portanto, se uma tabela tiver seis linhas e a ou-
tra tiver três, o product resulta em uma lista composta de 6x3=18 linhas. O efeito do product é
apresentado na Figura 9.
P_CODE P_DESCRIPT PRICE STORE AILSE SHELF

123456 Flashlight 5.26 23 W 5
PRODUCT
123457 Lamp 25.15 24 K 9
123458 Box Fan 10.99 25 Z 6
213345 9v Battery 1.99
resulta em
P_CODE P_DESCRIPT PRICE STORE AILSE SHELF

123456 Flashlight 5.26 23 W 5
123457 Flashlight 5.27 24 K 9
123458 Flashlight 5.28 25 Z 6
123457 Lamp 25.15 23 W 5
123458 Lamp 25.16 24 K 9
123459 Lamp 25.17 25 Z 6
123458 Box Fan 10.99 23 W 5
123459 Box Fan 10.100 24 K 9
123460 Box Fan 10.101 25 Z 6
213345 9v Battery 1.99 23 W 5
213346 9v Battery 1.100 24 K 9
213347 9v Battery 1.101 25 Z 6
Figura 9 Product.
Select
Este operador, também conhecido como restrict, resulta nos valores de todas as linhas
de uma tabela que satisfaçam uma dada condição. O select pode ser utilizado para listar todos
os valores de linha ou apenas aqueles que atenderem a um critério especificado. Em outras
palavras, select produz um subconjunto horizontal de uma tabela, e seu efeito é apresentado na
Figura 10.

Tabela original Nova tabela ou lista

P_CODE P_DESCRIPT PRICE SELECT ALL resulta P_CODE P_DESCRIPT PRICE
123456 Flashlight 5.26 em 123456 Flashlight 5.26
123457 Lamp 25.15 123457 Lamp 25.15
123458 Box Fan 10.99 123458 Box Fan 10.99
123459 9v Battery 1.99 123459 9v Battery 1.99
123460 Powerdrill 34.99 123460 Powerdrill 34.99
SELECT apenas atributo PRICE inferior a US$ 2,00 resulta em

123459 9v Battery 1.99
SELECT apenas atributo P_CODE = 123457 resulta em

123457 Lamp 25.15
Figura 10 Operador Select.
Project
A resultante deste operador será todos os valores de atributos selecionados. Em outras
palavras, o project produz um subconjunto vertical de uma tabela. Seu efeito é apresentado na
Figura 11:
Tabela original Nova lista de tabelas

P_CODE P_DESCRIPT PRICE PRICE
PROJECT PRICE
123456 Flashlight 5.26 5.26
resulta em
123457 Lamp 25.15 25.15
123458 Box Fan 10.99 10.99
123459 9v Battery 1.99 1.99
123460 Powerdrill 34.99 34.99
P_CODE P_DESCRIPT PRICE P_DESCRIPT PRICE

123456 Flashlight 5.26 PROJECT P_DESCRIPT e
Flashlight 5.26
123457 Lamp 25.15 PRICE resulta em
Lamp 25.15
123458 Box Fan 10.99 Box Fan 10.99
123459 9v Battery 1.99 9v Battery 1.99
123460 Powerdrill 34.99 Powerdrill 34.99
Figura 11 Operador Project.
Join
O operador join possibilita a combinação de informações de duas ou mais tabelas. Trata-
-se da potência real por trás dos bancos de dados relacionais, e permite a utilização de tabelas
independentes ligadas por atributos comuns. As tabelas CLIENTE e CORRETOR, apresentadas na
Figura 12, ilustram vários tipos de utilização do operador join (junções).
Nome da tabela: CLIENTE Nome da tabela: CORRETOR

CUS_CODE CUS_LNAME CUS_ZIP AGENT_CODE AGENT_CODE AGENT_PHONE
1234 Walker 31145 231 125 6152439887
1235 Adares 32145 125 167 6153426778
1236 Rakowski 34129 167 231 6152431124
1237 Rodriguez 37134 125 333 9041234445
1238 Smithson 37134 421
1239 Vanloo 32145 231
Figura 12 Tabelas para demonstrar o operador Join.
A junção natural (natural join) liga tabelas selecionando apenas as linhas com valores co-
muns em seu(s) atributo(s) comum(ns). É o resultado de um processo em três estágios:
a) Aplica-se o operador product nas tabelas.
b) Executa-se uma operação select sobre o resultado da Etapa a para se obter apenas as
linhas para as quais os valores AGENT_CODE são iguais. As colunas comuns são cha-
madas de colunas de junção.
c) Executa-se uma operação project sobre os resultados da Etapa b para produzir uma
única cópia de cada atributo, eliminando-se, assim, as colunas duplicadas.
O resultado da operação join entre CLIENTE e CORRETOR é demonstrado na Figura 13:
Figura 13 Tabela resultado do Join entre CLIENTE e CORRETOR.
O resultado de uma junção natural produz uma tabela que não inclui pares sem corres-
pondência. O resultado fornece apenas as cópias das correspondências.
Outra forma de junção, conhecida como junção por igualdade (equijoin), tem por fina-
lidade realizar a ligação entre tabelas com base em uma condição de igualdade que compara
colunas especificadas de cada tabela. O resultado da junção por igualdade não elimina colunas
duplicadas, e a condição ou critério utilizado para unir as tabelas deve ser definido explicitamen-
te. Esse tipo de junção recebe seu nome em função do operador de comparação de igualdade
(=) utilizado na condição.
Em uma junção externa (outer join), os pares com correspondência são mantidos e os va-
lores em correspondência na outra tabela são deixados nulos. De modo mais específico, se for
realizado uma junção externa para as tabelas CLIENTE e CORRETOR, há duas situações possíveis:

• Junção externa à esquerda (left outer join): resulta em todas as linhas da tabela CLIEN-
TE, inclusive aquelas que não apresentam um valor correspondente na tabela CORRE-
TOR. Um exemplo dessa junção é apresentado na Figura 14:
Figura 14 Junção externa à esquerda.
• Junção externa à direita (right outer join): resulta em todas as linhas da tabela CORRE-
TOR, inclusive aquelas que não apresentam um valor correspondente na tabela CLIEN-
TE. Veja o exemplo na Figura 15:
Figura 15 Junção externa à direita.
Junções externas são especialmente úteis quando se tenta determinar qual(is) valor(es)
de tabelas relacionadas causa(m) problemas de integridade referencial. Esses problemas são
criados quando valores de chave estrangeira não correspondem a valores de chave primária
da(s) tabela(s) relacionada(s).
Você deve estar se perguntando por que as junções externas são identificadas como à
esquerda e à direita. Esses nomes se referem à ordem em que as tabelas são relacionadas no
comando SQL.
Divide
A operação divide utiliza uma tabela com uma única coluna (por exemplo, a coluna A)
como o divisor e uma tabela de duas colunas (por exemplo, as colunas A e B) como o dividendo.
As tabelas devem ter uma coluna em comum (por exemplo, a coluna A). A saída da operação
divide é uma única coluna com os valores da coluna A e as linhas da tabela de dividendo, em que
o valor da coluna comum (por exemplo, a coluna A) coincide em ambas as tabelas. A Figura 16
apresenta a operação divide:
CODE LOC
A 5
CODE LOC
A 9 Resulta em
DIVIDE A A
A 4
B
B 5
B 3
C 6
D 7
D 8
E 8
Figura 16 Divide.
No exemplo apresentado na Figura 16, observe que:

• A Tabela 1 é dividida pela Tabela 2 para produzir a Tabela 3. As Tabelas 1 e 2 contêm a
coluna CODE, mas não compartilham a LOC.
• Para ser incluído na Tabela 3 resultante, um valor de uma coluna não compartilhada
(LOC) deve estar associada (na Tabela 2 de divisão) a todos os valores da Tabela 1.
• O único valor associado tanto a A como a B é 5.
11. RELACIONAMENTOS DENTRO DO BANCO DE DADOS RELACIONAL

Até o momento compreendemos a importância de se manter a integridade dos dados e
quais os seus tipos em um banco de dados. Conhecemos também os operadores básicos que
embasam os operadores SQL para a manipulação dos dados.
Estudaremos neste tópico os tipos de relacionamentos que podem ser utilizados para a
modelagem de um projeto de banco de dados, a fim de garantir melhor perfomance e, acima de
tudo, manter a integridade dos dados.
Você já sabe que os relacionamentos são classificados como um para um (1:1), um para
muitos (1:M) e muitos para muitos (M:N ou M:M). Veja, a seguir, mais informações sobre cada
um desses relacionamentos.
Relacionamento 1:M
O relacionamento 1:M é a norma do banco de dados relacional. Para ver como esse re-
lacionamento é modelado e implementado, considere o exemplo "o PINTOR cria a PINTURA".
Compare o modelo de dados na Figura 17 com sua implementação, na Figura 18:
Figura 17 Relacionamento 1:M entre PINTOR e PINTURA.

Nome da Tabela: PINTOR

Chave primária: PAINTER_NUM
Chave estrangeira: nenhuma
PAINTER_NUM PAINTER_LNAME PAINTER_FNAME PAINTER_INITIAL
123 Ross Georgette P
126 Itero Julio G
Nome da Tabela: PINTURA

Chave primária: PAINTING_NUM
Chave estrangeira: PAINTER_NUM
PAINTING_NUM PAINTING_TITLE PAINTER_NUM
1338 Dawn Thunder 123
1339 Vanilla Roses To Nowhere 123
1340 Tired Flounders 126
1341 Hasty Exit 123
1342 Plastic Paradise 126
Figura 18 Relacionamento 1:M implementado entre PINTOR e PINTURA.
Ao examinar o conteúdo da tabela PINTOR e PINTURA na Figura 18, observe os seguintes

aspectos:
• Cada pintura é criada por um e somente um pintor, mas cada pintor pode ter criado
várias pinturas. Observe que a Pintora 123 (Georgette P. Ross) possui três pinturas ar-
mazenadas na tabela PINTURA.
• Há apenas uma linha da tabela PINTOR para qualquer linha da tabela PINTURA, mas há
várias linhas da tabela PINTURA para qualquer linha da tabela PINTOR.
Relacionamento 1:1
Como o próprio nome diz, no relacionamento 1:1 uma entidade pode ser relacionada à
apenas outra entidade e vice-versa. Por exemplo, um chefe de departamento – um professor
– pode chefiar apenas um departamento, e um departamento pode ter apenas um chefe. As
entidades PROFESSOR e DEPARTAMENTO apresentam, portanto, um relacionamento 1:1.
O relacionamento 1:1 básico é modelado na Figura 19 e sua implementação é apresentada
na Figura 20.
Figura 19 Relacionamento 1:1 entre PROFESSOR e DEPARTAMENTO.

Nome da Tabela: PROFESSOR

Chave primária: EMP_NUM
Chave estrangeira: DEPT_CODE
EMP_NUM DEPT_CODE PROF_OFFICE PROF_EXTENSION PROF_HIGH_DEGREE
103 HIST DRE 156 3296 Ph.D.
104 ENG DRE 102 3328 MA
106 ACCT KLR 229 3392 Ph.D.
110 MKT/MGT KLR 229B 3520 Ph.D.
114 BIOL KLR 126 3648 Ph.D.
155 ACCT AAJ 89 4960 Ph.D.
160 MATH DBE 988 5120 Ph.D.
162 ENG KLR 1898 5184 Ph.D.
191 CIS DRE 293 6112 DBA
195 MKT/MGT AAK 192 6240 Ph.D.
209 PXYCH BBG 277 6688 Ph.D.
228 CIS DK 123 7296 Ph.D.
297 CIS DFK 134 9504 Ph.D.
299 MATH AAC 182 9568 Ph.D.
301 ECON/FUN ACE 282 9632 Ph.D.
335 ACCT CDE 122 10720 Ph.D.
342 ENG DKD 312 10944 Ph.D.
387 SOC RTE 152 12384 Ph.D.
401 BIOL DK 234 12832 MA
425 HIST DFR 13600 MBA
435 ECON/FUN DDF 39 13920 Ph.D.
O relacionamento 1:M “o DEPARTAMENTO emprega o PROFESSOR” é implementado por meio da

inserção da chave estrangeira DEPT_CODE na tabela PROFESSOR
O relacionamento 1:1 “o PROFESSOR chefia o

DEPARTAMENTO” é implementado por meio da inserção
da chave estrangeira EMP_NUM na tabela
Nome da Tabela: DEPARTAMENTO DEPARTAMENTO
Chave primária: DEPT_CODE
Chave estrangeira: EMP_NUM
DEPT_CODE DEPT_NAME SCHOOL_CODE EMP_NUM DEPT_EXTENSION
ACCT Accounting BUS 114 2933
ART FineArts ASCI 435 2832
BIOL Biology ASCI 387 4813
CIS Computer Info. Systems BUS 209 4821
ECON/FIN Economics/Finance BUS 299 3845
ENG English ASCI 160 2482
HIST History ASCI 103 3365
MATH Mathematics ASCI 297 3461
MKT/MGT Marketing/Management BUS 106 3471
PSYCH Psychology ASCI 195 5732
SOC Sociology ASCI 342 5735
Figura 20 Relacionamento 1:1 implementado entre PROFESSOR e DEPARTAMENTO.
Ao examinar as tabelas da Figura 20, observe que há vários aspectos importantes:

• Cada professor é um funcionário da Tiny College. Portanto, a identificação do professor
se dá por meio de EMP_NUM (número de funcionário). No entanto, observe que nem
todos os funcionários são professores, existindo outro relacionamento opcional.
• O relacionamento 1:1 "o PROFESSOR gerencia o DEPARTAMENTO" é implementado
com o EMP_NUM como chave estrangeira da tabela DEPARTAMENTO. Observe que
o relacionamento 1:1 é tratado como um caso particular do relacionamento 1:M, no
qual o lado muitos está restrito a uma única ocorrência. Nesse caso, DEPARTAMENTO
contém EMP_NUM como um chave estrangeira para indicar que é o departamento que
possui um gestor.

• Observe também que a tabela PROFESSOR contém a chave estrangeira DEPT_CODE

para implementar o relacionamento 1:M "o DEPARTAMENTO emprega o PROFESSOR".
Esse é um bom exemplo de como duas entidades podem participar de dois (ou mais)
relacionamentos simultâneos.
Relacionamento M:N
Para explorar o relacionamento muitos para muitos (M:N), considere um ambiente típico
de faculdade em que cada ALUNO possa estar em várias TURMAs e cada TURMA possa conter
vários ALUNOs. O modelo ER da Figura 21 mostra esse relacionamento M:N.
Figura 21 Relacionamento M:N do ER entre ALUNO e TURMA.
Observe os aspectos do ER da Figura 21:

• Cada TURMA pode ter vários ALUNOs e cada ALUNO pode estar em várias TURMAs.
• Pode haver muitas linhas na tabela TURMA para qualquer linha da tabela ALUNO e
pode haver muitas linhas da tabela ALUNO para qualquer linha da tabela TURMA.
Os problemas inerentes aos relacionamentos muitos para muitos (M:N) podem ser fa-
cilmente evitados, criando-se uma entidade composta (também chamada de entidade ponte
ou entidade associativa). Como essa tabela é utilizada para ligar as tabelas originalmente no
relacionamento M:N, a estrutura da entidade composta inclui, como chaves estrangeiras, pelo
menos as chaves primárias das tabelas que estão sendo ligadas.
É possível criar a tabela composta MATRÍCULA, exibida na Figura 22, para ligar as tabelas
TURMAS e ALUNO. Nesse exemplo, a chave primária da tabela é a combinação de suas chaves
estrangeiras CLASS_CODE e STU_NUM.
Figura 22 Conversão de um relacionamento M:N em dois relacionamentos 1:M.
Observe na Figura 23 que a entidade composta chamada MATRÍCULA representa a tabela

de ligação entre ALUNO e TURMA.
Figura 23 Alteração do relacionamento M:N em dois relacionamentos 1:M.
Índices
Suponha que se queira localizar um livro específico em uma biblioteca. Faria sentido olhar
todos os livros até encontrar o desejado? É claro que não: utiliza-se o catálogo da biblioteca,
que apresenta índices por título, assunto e autor. O índice (tanto em um sistema manual como
em computadores) aponta para o local do livro, transformando sua localização em uma solução
rápida e simples. Um índice é uma disposição ordenada utilizada para acessar logicamente as
linhas de uma tabela.
Suponha, ainda, que você queira encontrar um assunto como, por exemplo, o modelo ER
neste livro. Faria sentido ler todas as páginas até encontrar o tópico acidentalmente? Certamen-
te não. É muito mais simples recorrer ao índice do livro, procurar a expressão modelo ER e ler
as referências que apontam para a(s) página(s) adequada(s). Em cada caso, o índice é utilizado
para localizar rapidamente um item necessário.

De modo geral, um índice é uma disposição ordenada de chaves e ponteiros. Cada chave
aponta para a localização dos dados identificados por ela.
Imagine que você queira procurar as pinturas criadas por determinado pintor no banco de
dados da Figura 24. Sem um índice, é necessário ler todas as linhas da tabela PINTURA e ver se
o atributo PAINTER_NUM corresponde ao pintor solicitado. No entanto, indexando-se a tabela
PINTOR e utilizando-se a chave de índice PAINTER_NUM, basta procurar o valor adequado desse
atributo no índice e encontrar os ponteiros correspondentes. Em termos conceituais, o índice se
assemelha à apresentação ilustrada na Figura 24.
Figura 24 Componentes de um índice.
Ao examinar a Figura 24, observe que o primeiro valor da chave de índice PAINTER_NUM
(123) encontra-se nos registros 1, 2 e 4 da tabela PINTURA da Figura 18. O segundo valor PAIN-
TER_NUM (126) encontra-se nos registros 3 e 5 dessa mesma tabela.
Os SGBDs utilizam índices para finalidades muito diferentes. Você pôde aprender que os
índices podem ser utilizados para recuperar dados de modo mais eficiente, mas os SGBDs tam-
bém podem aplicá-los para recuperar dados ordenados por um ou vários atributos específicos.
A criação de um índice de sobrenome de clientes, por exemplo, permitirá a recuperação alfabé-
tica dos dados de clientes a partir de seus sobrenomes. Além disso, a chave de índice pode ser
composta por um ou mais atributos.
Os índices executam um papel importante nos SGBDs para a implantação das chaves pri-
márias. Ao se definir a chave primária de uma tabela, o SGBD cria automaticamente um índice
exclusivo para a(s) coluna(s) dessa chave.
12. PROJETO LÓGICO DE BANCO DE DADOS: MAPEAMENTO DO MODELO

ENTIDADE-RELACIONAMENTO PARA O MODELO RELACIONAL
Anteriormente, foram definidas as relações para o projeto de um banco de dados simples
para uma escola, cujo modelo entidade-relacionamento foi demonstrado na Unidade 2. Neste
tópico, mostraremos, passo a passo, como converter o projeto conceitual de um banco de dados
para o projeto lógico.
Você deve ter em mente as fases de construção de um banco de dados para facilitar as con-
versões do DER (diagrama entidade-relacionamento) para o modelo relacional. Vale relembrar
que o modelo entidade-relacionamento é utilizado durante o projeto conceitual e o modelo de
dados relacional, durante o projeto lógico da base. Com isso, é natural pensar em um algoritmo
que traduza os conceitos de um dos modelos (DER) nos conceitos do outro (relacional). Isso pode
ser realizado de acordo com os seguintes passos:
1) Para cada tipo de entidade-forte E no diagrama entidade-relacionamento (DER), crie
um esquema de relação R que inclua todos os atributos simples de E. Sobre os atribu-
tos compostos, inclua os atributos simples que os compõem. Escolha um dos atribu-
tos-chave de E como chave primária de R. Se a chave escolhida é composta, o conjunto
dos atributos simples dessa chave forma a chave primária de R. Através do diagrama
entidade-relacionamento representado pela Figura 25, você pode identificar que o
atributo código constitui a chave primária da entidade ora nomeada de aluno, e o
atributo endereço é composto pelos atributos simples rua, número e bairro.
Idade
Telefone Rua
Endereço Número
Nome
Sexo
Nascimento
Figura 25 ALUNO (Código, Nome, Sexo, Nascimento, Rua, Número, Bairro).
2) Para cada tipo de entidade-fraca F no diagrama ER, crie um esquema de relação R

que inclua todos os atributos simples de F. Além disso, inclua como chave estrangeira
de R os atributos que formam a chave primária do esquema de relação associado à
entidade proprietária E de F. A chave primária de R é uma combinação da chave pri-
mária de E com a chave parcial de F. A Figura 26, através do diagrama-relacionamento,
apresenta um exemplo de entidade-fraca chamada de dependente, a qual possui uma
chave primária composta formada pelos atributos NSS e Nome, onde o atributo NSS
é uma chave estrangeira que referencia a chave primária da entidade identificada de
empregado.

CE
Figura 26 DEPENDENTE (NSS, Nome, Data_nasc, Relação, Sexo).
3) O diagrama ER identificado na Figura 27 demonstra cada tipo de relacionamento bi-

nário R 1:1 no diagrama ER. Identifique os esquemas de relação S e T que dele parti-
cipam. Escolha uma das relações, digamos S, e inclua como chave estrangeira de S a
chave primária de T. Inclua todos os atributos simples de R como atributos de S. Ou
seja, você pode identificar que o atributo nome forma a chave primária da entidade
departamento. Como se trata de um relacionamento 1:1, no qual um empregado
pode apenas gerenciar um único departamento e, por sua vez, um departamento
pode ser gerenciado por no máximo um empregado, torna-se necessário inserirmos
uma chave estrangeira em departamento. Essa chave é identificada de NSS, que refe-
rencia a chave primária da entidade empregado.
CE
Figura 27 DEPARTAMENTO (Nome, Número, NSS).
Nesse caso, em que a cardinalidade é 1:1, escolhe-se o lado no qual se deve colocar a
chave estrangeira. Na prática, é melhor fazer essa "escolha" no momento do DER, que deixaria
o relacionamento conforme demonstrado na Figura 28:
Figura 28 Mapeamento de relacionamento binário (cardinalidade 1:M).
4) Para cada tipo de relacionamento binário R 1:M, identifique o esquema S que repre-
senta o tipo de entidade do lado M de R. Inclua como chave estrangeira de S a chave
primária do esquema T que representa o outro tipo de entidade (do Lado 1). Inclua
todos os atributos simples de R como atributos de S. Você pode perceber que, ao
realizamos o mapeamento da entidade turma, representada pela Figura 29, foi neces-
sário incluir o atributo codigo_curso, que, devido à cardinalidade 1:M, é uma chave
estrangeira que referencia a chave primária da entidade curso.
Nome
Código
(1,M) (1,1)
Curso Turma
Possui
Código
Período Letivo
Início
Término
CE
Figura 29 TURMA (Codigo_Tur, Periodo_letivo, Dta_inicio, Dta_termino, Codigo_curso).
5) Para cada tipo de relacionamento binário R M:M, crie um novo esquema de relação
S para representá-lo. Inclua como chave estrangeira de S as chaves primárias dos es-
quemas de relação que representam os tipos de entidade participantes do relacio-
namento. A combinação dessas chaves forma a chave primária de S. Inclua todos os
atributos simples de R como atributos de S. Na Figura 30, que ilustra um exemplo
de um diagrama ER, você constatará a necessidade de criarmos um novo esquema,
este identificado de professor_leciona_disciplina, que é formado pelos atributos co-
digo_prof e codigo_disc. Ambos formam a chave primária composta dessa entidade
e também são chave estrangeira, ou seja, codigo_prof referencia a chave primária da
entidade professor e codigo_disc referencia a chave primária da entidade disciplina.

Código Professor
(1,M)
Nome
Título leciona
(1,M)
Código Disciplinas
(1,M)
Nome
oferecida
CE
Figura 30 PROFESSOR_LECIONA_DISCIPLINA (Codigo_prof, Codigo_disc).
6) Para cada atributo multivalorado A, crie um novo esquema de relação R. Esse esque-
ma incluirá dois atributos: um correspondente a A e outro correspondente à chave
primária K do esquema que representa o tipo de entidade que possui A como atribu-
to. A chave primária de R é a combinação de A e K. Perceba que, quando realizamos o
mapeamento da entidade aluno, ilustrada na Figura 31, torna-se necessário a criação
de um esquema, esse identificado de telefone_aluno, formado pelos atributos codi-
go_alu e telefone, onde codigo_alu é a chave estrangeira que referencia a chave pri-
mária da entidade aluno, pelo simples fato de o atributo telefone ser multivalorado.
Idade
Telefone Rua
Endereço Número
Nome
Sexo
Nascimento
CE
Figura 31 TELEFONE_ALUNO (Codigo_alu, Telefone).
7) Para cada tipo de relacionamento m-ário R, em que M>2, crie um novo esquema de
relação S para representar R. Inclua como chaves estrangeiras em S as chaves primá-
rias dos esquemas de relação relacionados aos tipos de entidades que participam do
relacionamento. Inclua todos os atributos simples de R como atributos de S. A chave
primária de S corresponde à combinação de todas as chaves estrangeiras que referen-
ciam os esquemas de relação das entidades participantes do relacionamento. A Figura
32 representa esse tipo de relacionamento, tornando-se necessário a realização do
mapeamento do relacionamento identificado de matricula-se, que, a partir de agora,
passa a ser uma entidade, a qual é nomeada de matrícula, formada pelos atributos
codigo_tur, codigo_disc, codigo_prof e codigo_alu. Todos esses atributos, chaves es-

trangeiras, referenciam respectivamente suas chaves primárias correspondentes.
cod_turma
Nota_1B
dsc_turma
Turma
Nota_B
Desempenho
Media_Final
(1,M)
(1,M) (1,M)
Aluno matricula-se Professor
cod_aluno
(1,M) cod_prof
nom_aluno
nome_prof
end_aluno Disciplina end_prof
fone_aluno cod_disc fone_prof
dta_nascimento nom_disc
carga_horaria_disc
CE CE CE CE
Figura 32 MATRICULA (Codigo_tur, Codigo_Disc, Codigo_Prof, Codigo_alu).
O relacionamento descrito é um relacionamento quaternário. Quando há três entidades

envolvidas, chamamos de relacionamento ternário.
Considerando o banco de dados escolar demonstrado na Unidade 2, você verá, a seguir,
um exemplo de banco de dados lógico.
De acordo com os sete passos mencionados anteriormente, definiremos, agora, as entida-
des e os atributos das entidades.
Por exemplo, no caso do banco de dados escolar (Figura 33), você deve, inicialmente, se-
guir o Passo 1. Logo você terá as seguintes entidades:

Nome
Idade
Código Professor
Código
(1, M) Telefone Rua
Nome

Título

(1, M) (1, M)
Nome
Disciplina Possui
Código
Sexo
(1, M) (1, M)
Nome
Nascimento
oferecida (1, M)
Turma (1, M)
matricula-se
(1, M)
Figura 33 DER Sistema Escolar.
1) PROFESSOR (Codigo, Nome, Titulo).

2) DISCIPLINA (Codigo, Nome).
3) CURSO (Codigo, Nome).
4) TURMA (Codigo, Periodo_letivo, Inicio, Termino).
5) ALUNO (Codigo, Nome, Sexo, Nascimento, Rua, Numero, Bairro, Cidade).
Na sequência, vá para o Passo 2; veja que, neste exemplo, não temos nenhuma entidade-
-fraca. Seguindo as instruções dos Passos 3, 4 e 5, teremos as seguintes chaves estrangeiras em
cada relação:
PROFESSOR (Codigo, Nome, Titulo)
DISCIPLINA (Codigo, Nome)

CE CE
PROFESSOR_LECIONA_DISCIPLINA (Codigo_prof, Codigo_disc)
CURSO (Codigo, Nome)

CE
TURMA (Codigo, Codigo_curso, Periodo_letivo, Inicio, Termino)
CE CE
DISCIPLINA_OFERECIDA_TURMA (Codigo_disc, Codigo_tur)
ALUNO (Codigo, Nome, Sexo, Nascimento, Rua, Numero, Bairro, Cidade)

CE CE
MATRÍCULA (Codigo_alu, Codico_tur, Dta_matricula, Dta_cancelamento, Mot_
cancelamento)
Note que a relação MATRICULA não tem "número de alunos", que é um atributo derivado,
ou seja, ele pode ser consultado por meio de uma pesquisa contando-se o número de alunos.
Assim, ele só existe no DER, e o mesmo acontece com a IDADE do aluno, que pode ser calculada
subtraindo sua data de nascimento da data atual.
No Passo 6, é fundamental que você localize cada atributo multivalorado e crie uma nova
relação. Dessa forma, foi criada a relação TELEFONE_ALUNO. Para a relação MATRICULA, a "data
da matrícula" fará parte da chave primária, uma vez que a MATRICULA já é uma nova relação e,
por fazer parte da chave primária, será possível cadastrar várias datas de matrícula.
O banco de dados escolar terá a seguinte estrutura:
PROFESSOR (Codigo, Nome, Titulo)
DISCIPLINA (Codigo, Nome)

CE CE
PROFESSOR_LECIONA_DISCIPLINA (Codigo_Prof, Codigo_disc)
CURSO (Codigo, Nome)

CE
TURMA (Codigo, Codigo_curso, Periodo_letivo, Inicio, Termino)
CE CE
DISCIPLINA_OFERECIDA_TURMA (Codigo_disc, Codigo_tur)
ALUNO (Codigo, Nome, Sexo, Nascimento, Rua, Numero, Bairro, Cidade)

CE
TELEFONE_ALUNO (Código_alu, Telefone)
CE CE
MATRICULA (Codigo_alu, Codigo_tur, Dta_matricula, Dta_cancelamento, Mot_
cancelamento)
Considerando o modelo escolar, para o Passo 7, não há nenhum relacionamento M-ário.

Na próxima unidade, você aprenderá como gerar o SQL deste banco de dados aplicando restri-
ções e todos os conceitos envolvidos até o momento.

unidade:
1) Defina e exemplifique os seguintes conceitos
a) Chave candidata.
b) Chave estrangeira.
2) Quais são as principais regras de integridade de entidades?
3) Quais são as principais regras de integridade referencial?
4) Quais são os principais operadores pertinentes ao conjunto relacional?
5) Exemplifique os seguintes relacionamentos:

a) Relacionamento 1:M.
b) Relacionamento 1:1.
c) Relacionamento M:N.
6) A questão a seguir utilizou os dados de um banco de dados simplificado, apresentado pelas tabelas CLIENTE,
PEDIDO e ITEM, dispostos na Figura 34.

Figura 34 Tabelas CLIENTE, PEDIDO e ITEM.
No modelo apresentado, a especificação de chave primária correta é:

a) atributo id_item na tabela Item.
b) atributo id_loja na tabela Pedido.
c) atributo id_pedido na tabela Item.
d) atributo nome na tabela Cliente.
e) Atributos id_pedido, id_item na tabela Item.
7) Pode-se afirmar que os relacionamentos entre as tabelas Cliente e Pedido e entre as tabelas Pedido e Item são,
respectivamente:
a) 1:1 e 1:N.
b) 1:N e 1:1.
c) 1:N e 1:N.
d) 1:N e N:N.
e) N:N e 1:N.
Gabarito
6) e.
7) c.
14. CONSIDERAÇÕES
Nesta unidade, você teve a oportunidade de conhecer o Modelo Relacional, ou seja, um
Modelo de Dados Lógico para o ambiente escolar.
O aprendizado passo a passo do processo de mapeamento do esquema conceitual para o

esquema relacional permitiu a compreensão de como iniciar a formulação e criação do banco
de dados relacional.
As relações do banco de dados para uma escola, apresentadas na Unidade 2, foram utili-
zadas para exemplificar as tabelas e aplicar restrições de integridade. Nesta unidade, também
foram apresentados alguns comandos básicos da linguagem SQL. A confecção de consultas mais
completas e complexas exigirá o conhecimento de Álgebra Relacional (ver Apêndice 3) e o uso
da linguagem SQL, que será discutida na próxima unidade.
Para que compreenda melhor os conceitos apresentados, sugerimos que você retorne a
esta unidade após o estudo da Unidade 4.
Bons estudos!
15. E-REFERÊNCIAS
ALVARENGA, J. P. Informática: Banco de Dados I. Disponível em :<http://pt.scribd.com/doc/34137068/9/RELACIONAL>. Acesso
em: 23 out. 2012.
DFC-UFMS. Disponível em: <http://www.dct.ufms.br/~said/disciplinas/bd/bd.html>. Acesso em: 14 jan. 2008.

ELMASRI, R.; NAVATHE, S.B. Sistemas de bancos de dados. São Paulo: Pearson (Addison Wesley), 2005.
RAMAKRISHNAN, R. GEHRKE, J. Database management systems. 2. ed. Boston: McGraw-Hill, 2000.

SQL – Uma Linguagem de
Consulta
1. OBJETIVOS
• Compreender os conceitos da Linguagem SQL, seu funcionamento e aplicações práti-
cas.
• Construir aplicações utilizando a Linguagem SQL.
2. CONTEÚDOS
• Linguagem SQL.
• Principais operações para atualização dos dados.
• Estrutura da Linguagem SQL.
• Aplicação da Linguagem utilizando PostgreSQL.
• Introdução à Linguagem SQL avançada.
• Introdução às Visões.

guir:
1) Sua formação é essencial, pois ela determinará posturas e escolhas no desenvolvi-
mento de sua prática. Invista em você, faça da pesquisa e da interação com seus cole-
gas de curso e tutor um hábito, o qual poderá ajudá-lo a ampliar e a aprofundar seus
conhecimentos.
2) Para executar os comandos SQL, apresentados nesta unidade, você deverá ter insta-
lado o SGBD PostgreSQL. Veja, no Apêndice 1, todos os passos para a sua instalação.
3) Conheça o site do American National Standards Institute (ANSI), disponível em:
<http://www.ansi.org>. Acesso em: 4 out. 2012.
4) Para que você possa dar continuidade aos estudos das demais unidades, é fundamen-
tal ter pleno conhecimento dos conceitos da linguagem SQL. Para isso, sugerimos que
você pratique os exemplos apresentados no decorrer desta unidade.
5) Além dos exercícios apresentados neste estudo, consulte outras referências. Fique à
vontade para compartilhar listas de exercícios e trocar ideias sobre como resolvê-los
com seus colegas de turma e com seu tutor pela Sala de Aula Virtual.
6) Atente para algumas observações importantes para o estudo desta unidade: introdu-
ção à linguagem SQL básica e avançada e principais operações para atualização dos
dados utilizando o PostgreSQL. Recorra aos exemplos apresentados na unidade, faça
consultas usando vários recursos, pois isso torna seu aprendizado mais estimulante e
desafiador.
Na unidade 3, você teve a oportunidade de aprender que os Sistemas Gerenciadores de
Bancos de Dados baseiam-se no modelo relacional e que é, a partir dele, que se desenvolve um
modelo de banco de dados relacional, fazendo o mapeamento do modelo entidade-relaciona-
mento para o modelo relacional.
Nesta unidade, você trabalhará com a linguagem SQL, que é a linguagem utilizada para
criação e manipulação de bancos de dados a partir dos Sistemas Gerenciadores de Bancos de
Dados Relacionais.
5. LINGUAGEM SQL
A linguagem SQL (Structured Query Language – Linguagem de Consulta Estruturada) não é
uma linguagem de programação de computadores criada com o propósito de desenvolver siste-
mas, como as linguagens Pascal, C, Basic, Cobol, Java, C/C++, C#, dentre outras. Trata-se de uma
linguagem declarativa, cuja finalidade é facilitar o acesso às informações por meio de consultas,
atualizações e manipulações de dados, os quais são armazenados em bancos de dados relacionais.
A linguagem SQL foi criada pela IBM (International Business Machine) e desenvolvida pelo
PhD Donald D. Chamberlin, em 1974, com o nome Structured English Query Language (SEQUEL).
A linguagem de consulta estruturada SEQUEL foi disponibilizada para uso de um banco de dados
relacional da própria IBM, agora denominada de SEQUEL-XRM (1974-1975). Entre o período
correspondente a 1976 e 1977, a IBM realizou uma revisão da linguagem SEQUEL, nomeando-
-a de SEQUEL/2, a qual, posteriormente, passou a ser conhecida e referenciada pela sigla SQL.
Em 1979, participantes do projeto de desenvolvimento do SYSTEM/R fundaram uma em-
presa, por ocasião denominada Relational Software Inc., que disponibilizou o primeiro Sistema
de Gerenciamento de Banco de Dados Relacional Comercial, totalmente baseado na linguagem
SQL. Esse SGBD, intitulado de Oracle (o mesmo Oracle atualmente conhecido), foi pioneiro na
forte concorrência junto à IBM.
Entre 1980 e 1981, a IBM implementou a linguagem SQL nos seus Sistemas de Geren-
ciamento de Bancos de Dados Comerciais (BD2 – DataBase2 e SQL/Data), garantindo que essa
linguagem de consulta estruturada SQL se tornasse um padrão.
© U4 – SQL – Uma Linguagem de Consulta 111
Devido a sua boa aceitação no mercado, surgiram os primeiros problemas operacionais,

pois cada empresa passou a incorporar funcionalidades e comandos próprios à linguagem SQL,
diferenciando-a da sua forma original. Na tentativa de anular tais problemas, surge, nesse ce-
nário, o ANSI (American National Standards Institute), o qual passou a estabelecer, por meio de
um Comitê, normativas e critérios para definição de padrões para a linguagem SQL, que a partir
desse período passou a ser referenciada ANSI/SQL. Em 1986, foi criado o primeiro padrão oficial
para a linguagem SQL, nomeado de SQL/86. No ano seguinte, o ANSI, junto à ISO (International
Standards Organizations), desenvolveu uma extensão ao padrão SQL, constituindo o segundo
padrão para a linguagem SQL (SQL/89). Em 1992, firmando a parceria estabelecida entre ANSI
e ISO, um novo padrão foi apresentado, agora denominado SQL2 (SQL/92). O quarto padrão foi
oficialmente apresentado em 1999, intitulado de SQL3 (SQL/99). Por fim, em 2003, foi apresen-
tada a última revisão da linguagem SQL, com a definição do padrão SQL/2003, que incorporava,
dentre outros recursos diferenciais, recursos relacionados ao padrão XML (Extensible Markup
Language).
Apesar dos inúmeros esforços de entidades e institutos de padronização para construir
um padrão de trabalho adequado, infelizmente ainda existem empresas que implementam ro-
tinas, funções e comandos totalmente fora do padrão estabelecido, dificultando a vida dos pro-
fissionais da área de Tecnologia da Informação (TI). Em alguns casos isolados, essas empresas
utilizam mais de um Sistema de Gerenciamento de Banco de Dados em um mesmo ambiente
operacional.
A linguagem SQL utilizada no SGBD PostgreSQL é segmentada em quatro subconjuntos
que formam a base das instruções – DDL (Data Definition Language), DML (Data Manipulation
Language), DCL (Data Control Language) e DQL (Data Query Language) –, podendo, ainda, in-
cluir os subconjuntos SRC (Stored Routines Commands) e DTC (Data Type Commands). Veja suas
características a seguir:
DDL – Data Definition Language (Linguagem de Definição de Dados)

Este subconjunto oferece recursos para definir objetos e controlar dados, ou seja, são
comandos responsáveis pela estruturação do banco de dados, como a própria criação do banco
de dados (database), criação das tabelas, dos índices, dentre outras possibilidades. Podemos
mencionar alguns comandos que constituem a DDL, como: ALTER TABLE, CREATE DATABASE,
CREATE INDEX, CREATE TABLE, CREATE VIEW, DROP DATABASE, DROP INDEX, DROP TABLE, DROP
VIEW, entre outros.
DML – Data Manipulation Language (Linguagem de Manipulação de Dados)

Subconjunto de comandos que tem como finalidade promover mecanismos para mani-
pulação e gerenciamento dos bancos de dados, inserindo, alterando e removendo os dados. Os
comandos que constituem esse subconjunto são: DELETE, INSERT, UNION E UPDATE.
DCL – Data Control Language (Linguagem de Controle de Dados)

Comandos responsáveis por oferecer recursos de controle de acesso de usuários ao sis-
tema e aos dados, estabelecendo regras para realização de consultas, inserções, modificações
e exclusões de dados do banco de dados. A linguagem DCL é constituída pelos comandos: AL-
TER USER, CREATE GROUP, CREATE ROLE, DROP GROUP, CREATE USER, DROP ROLE, DROP USER,
GRANT E REVOKE.

DQL – Data Query Language (Linguagem de Pesquisa de Dados)

É considerado por alguns autores como um comando pertencente ao subconjunto Data
Manipulation Language, pelo simples fato de ser manipulado em conjunto com outros coman-
dos DML. É formado apenas pelo comando SELECT.
SRC – Stored Routines Commands (Comandos de Rotinas Armazenadas)

Comandos que permitem a utilização de códigos de sub-rotinas armazenadas no SGBD,
tais como: AFTER, AS, BEFORE, BEGIN, CALLED, CREATE, DECLARE, DEFINER, EACH, ELSE, EL-
SIF, END, EXCEPTION, EXECUTE, EXTERNAL, FOR, FUNCTION, IF, IMMUTABLE, INPUT, INVOKER,
LANGUAGE, LOOP, NEW, NOTICE, NULL, OLD, ON, OR, PROCEDURE, RAISE, REPLACE, RETURN,
RETURNS, ROW, SECURITY, entre outros.
DTC – Data Type Commands (Comandos de Tipos de Dados)

Grupo de comandos responsáveis por estabelecer o tipo de dado que uma coluna (campo/
atributo) armazena em uma tabela específica. Os comandos que formam o DTC são: BIGINT, BI-
GSERIAL, CHAR, CHARACTER, DATE, DECIMAL, DOUBLE, INTEGER, INT, MONEY, NUMERIC, REAL,
SERIAL, SMALLINT, TIME E VARCHAR.
É importante destacar que além dos comandos descritos, existe um conjunto de funções
predefinidas, como uma série de operadores que promovem facilitadores nas diversas ações
realizadas pelos aplicativos.
6. HISTÓRICO DO POSTGRESQL
O software PostgreSQL é um Sistema de Gerenciamento de Banco de Dados Objeto-Rela-
cional (SGBDOR), desenvolvido no Departamento de Ciência da Computação da Universidade da
Califórnia, em Berkeley. Sua distribuição é realizada em regime open source, como uma conside-
rável alternativa aos Sistemas de Gerenciamento de Banco de Dados Oracle, SQL Server, MySQL,
dentre outros.
No início de 1987, com objetivo de demonstrar o SGBD, uma versão preliminar foi liberada.
Entretanto, foi apenas no final de 1987 que ocorreu a liberação da versão 1.0 na Conferência ACM-
-SIGMOD, para um grupo restrito de usuários. Em 1990, a versão 2.0 foi liberada com inúmeras
melhorias em relação à primeira versão. A última versão oficial (versão 4.2) foi desenvolvida pela
Universidade da Califórnia em Berkeley. Andrew Yu e Jolly Chen, em 1994, incluíram ao SGBD um
interpretador da linguagem SQL, lançando um novo produto, ora nomeado de Postgres95.
O SGBD Postgres95 decolou rapidamente pelo fato de ter sido liberado livremente pela
internet e por apresentar melhor desempenho (cerca de 30% a 50%) comparado ao Postgres4.2.
Devido à associação do nome ao ano de 1995 (Postgres95), o grupo de desenvolvimento decidiu
alterar seu nome para PostgreSQL, nome pelo qual é conhecido atualmente. A versão utilizada
nesta obra para o Sistema de Gerenciamento de Banco de Dados PostgreSQL é a versão 9.0,
disponibilizada em setembro de 2011.
7. PRINCIPAIS OPERAÇÕES PARA MANIPULAÇÃO DE DADOS

Para interagirmos com as principais operações de manipulação de dados, é necessário ini-
ciar a ferramenta pgAdmin III, realizar a conexão com o Sistema Gerenciador de Banco de Dados
por meio da autenticação (login), utilizando o usuário root, nomeado de Postgres, e informar o
respectivo password, configurado na instalação do SGBD (conforme Anexo 1).
O primeiro passo para o desenvolvimento de um banco de dados é definir seu esquema.
Para isso, utiliza-se o comando CREATE DATABASE.
Exemplo:
CREATE DATABASE NOME
[ARGUMENTOS]
Em que:
1) Apenas o valor da variável NOME é obrigatório (representa o nome do banco de dados
(database) que será criado).
a) NOME: espaços em branco e caracteres especiais devem ser evitados.
2) Argumentos opcionais podem ser usados, como:
a) OWNER: usuário responsável pelo banco de dados que será criado.
b) TEMPLATE: permite criar um banco de dados seguindo um modelo estrutural pre-
existente.
c) ENCODING: indica qual o conjunto de caracteres que o banco de dados utilizará
(moeda corrente e acentuação).
d) TABLESPACE: define a qual tablespace este banco de dados pertencerá.
e) CONNECTION LIMIT: permite limitar o número de conexões simultâneas (-1 cor-
responde a infinitas conexões).
Exemplo:
CREATE DATABASE "FACULDADE"
TEMPLATE = TEMPLATE0
ENCODING 'WIN1252'
CONNECTION LIMIT -1;
Os comandos anteriores criam o banco de dados nomeado FACULDADE. Na sequência,

é necessário trocar de banco de dados (database), visto que o banco de dados Postgres não
poderá conter nenhum objeto. Ou seja, esse banco de dados é utilizado apenas para funções
administrativas, como a criação de novos bancos de dados, realização de tuning, dentre outras
funcionalidades.
A remoção de um banco de dados (esquema) é proveniente do comando DROP DATABASE
via interface pgAdmin III e/ou via interface de linha de comando (psql), por meio do comando
DROPDB. A seguir, temos um exemplo do comando que realiza a remoção do database (esque-
ma) identificado como FACULDADE, via interface pgAdmin III.
Exemplo:
DROP DATABASE "FACULDADE"
Observação: na necessidade de desconectar-se do banco de dados, o qual queremos ex-

cluir/remover, normalmente utilizamos o banco de dados (esquema/database) padrão nomea-
do Postgres.
Já conectado corretamente ao banco de dados FACULDADE, talvez seja necessário extrair
algum tipo de informação das variáveis de ambiente do SGBD. Por exemplo, a identificação da
versão do servidor de banco de dados, por meio da instrução SELECT VERSION(), composta pelo
instrução SELECT juntamente à função VERSION().

Exemplo:
SELECT VERSION();
Imagine, agora, que necessitamos obter informações sobre a data atual do SGBD. De acor-
do com o exemplo a seguir, podemos extrair esse tipo de informação utilizando a instrução
SELECT CURRENT_DATE, obtendo, assim, a informação da data de acordo com as regras norte-
-americanas (AAAA-MM-DD), em que AAAA corresponde ao ano, MM ao mês e DD ao dia.
Exemplo:
SELECT CURRENT_DATE;
Exibida a data, seria também oportuno obter a hora atual do servidor (SGBD), por meio da
instrução SELECT CURRENT_TIME, formada pelo comando SELECT e a função CURRENT_TIME.
Observe que a hora será exibida no formato HH:MM:SS, em que HH corresponde às horas, MM
aos minutos e SS aos segundos.
Exemplo:
SELECT CURRENT_TIME;
A função NOW() é utilizada para exibir a data e a hora simultaneamente, podendo ser uti-
lizada junto à instrução SELECT, formando o comando SELECT NOW().
Exemplo:
SELECT NOW();
Além das informações de data e hora (NOW()), hora atual do servidor (CURRENT_TIME)
e versão atual do servidor de banco de dados (VERSION()), é permitido, também, extrairmos
informações sobre o usuário atual conectado no banco de dados, por meio da instrução SQL.
Veja a seguir:
Exemplo:
SELECT CURRENT_USER();
Calculadora do PostgreSQL
Por meio da instrução SELECT, o PostgreSQL permite a realização de diversas operações
aritméticas como adição (+), subtração (-), multiplicação (*), divisão (/) e resto de divisão (%). O
comando a seguir obtém o resultado de quatro operações aritméticas em uma única instrução
SELECT. Podemos lançar uso de parênteses, alterando a prioridade com que as operações serão
executadas.
Exemplo:
SELECT 3 + 8.3, 4 - 2.3, 5 * 3.21, 6 / 0.23;

SELECT (3 * 6) + 0.24;
Além das operações aritméticas básicas, o PostgreSQL possui um conjunto de funções

matemáticas internas, como funções para: calcular um valor absoluto, obter o resto da divisão,
realizar arredondamento de valores numéricos, exponencial, logaritmo, potência, dentre ou-
tras. Veja essas funções na Tabela 1:
Tabela 1 Funções matemáticas internas.

OPERADOR OPERAÇÃO TIPO RESULTADO
+ Manutenção de sinal Operador aritmético Positivo
- Inversão de sinal Operador aritmético Negativo
POWER(X, N) Exponenciação Função Real
SQRT(X) Raiz quadrada de X Função Real
POWER(X, (1/N)) Raiz de índice qualquer Função Real
Divisão de X por N com
TRUNC(X / N) Função Inteiro
quociente inteiro
MOD(X, N) Resto da divisão de X por N Função Inteiro
/ Divisão com quociente real Operador aritmético Real
* Multiplicação Operador aritmético Inteiro ou Real
+ Adição Operador aritmético Inteiro ou Real
- Subtração Operador aritmético Inteiro ou Real
% Resto da divisão Operador aritmético Inteiro
A precedência de processamento dos operadores aritméticos segue de acordo com sua

prioridade matemática. Por exemplo, a realização das operações de radiação e exponenciação
precede as operações de multiplicação, divisão, adição e subtração, consecutivamente.
Um banco de dados é formado por tabelas, as quais são criadas por meio do comando
CREATE TABLE. Para definir este comando, utilizaremos como base o modelo relacional, já nor-
malizado, ou seja, já extraídas as anomalias de inserção, exclusão e alteração. Para cada relação
constante no modelo relacional, você deverá criar um comando CREATE TABLE: cada uma das
relações é, na verdade, uma tabela do banco de dados.
Para tanto, utilizaremos, nesta obra, o PostgreSQL, que é um gerenciador de bancos de
dados (que está descrito no Apêndice 1). Ele instalará em seu computador todas as ferramentas
necessárias para que você possa acompanhar plenamente o conteúdo. Para acessar suas bases
de dados, é necessário utilizar uma ferramenta de manipulação e gerenciamento de bases de
dados, que, neste caso, corresponde ao pgAdmin III.
Os componentes mais importantes de um banco de dados são as tabelas, pois permitem a
manipulação dos registros e a manutenção de bancos de dados, ou seja, local onde uma coleção
de dados é inserida. A criação de tabelas por meio da linguagem SQL utiliza a instrução CREATE
TABLE, seguida do nome da tabela, bem como de outros argumentos para determinação de sua
estrutura. A sintaxe básica do comando CREATE TABLE é:
CREATE TABLE nome da tabela (

COLUNA1 TIPO DE DADOS [restrição],
COLUNA2 TIPO DE DADOS [restrição],
PRIMARY KEY (coluna1, coluna2),
FOREIGN KEY (coluna1) REFERENCES nome da tabela (colunas)
CONSTRAINT restrição
);

O nome da tabela é a indicação do nome da tabela a ser criada no banco de dados, co-
luna1 e coluna2 (campo) são a indicação dos nomes dos campos a serem definidos e tipo de
dados define o tipo de dado a partir de uma lista de tipos padrão.
O PostgreSQL trabalha com diversos tipos de dados, classificados de acordo com o con-
teúdo que será utilizado em uma determinada coluna. Os principais tipos de dados suportados
pelo nosso SGBD, ou seja, os tipos de dados (atributos) mais usuais podem ser visualizados no
Quadro 1.
Quadro 1 Tipos de dados.

TIPO DE DADO DESCRIÇÃO
Representa valores inteiros da faixa de
Bigint
-9.223.372.036.854.775.808 até 9.223.372.036.854.775.807.
Gera um valor único sequencial para um novo registro entre 1 e
BigSerial
9.223.372.036.854.775.807.
São sequências de caracteres de tamanho fixo limitados a 255
caracteres de comprimento. O parâmetro tamanho determina o
Char (tamanho) ou valor máximo em caracteres que pode conter a sequência. Esse tipo de dado,
Character (tamanho) quando definido, preenche o campo com espaços em branco até completar o
total de caracteres definidos, quando a totalidade do tamanho do campo não
é preenchida.
Data de calendário no formato AAAA-MM-DD (formato ANSI) com intervalo
Date
de tempo de 4.713 AC a 5.874.897 DC.
Decimal Determina a precisão do valor de casas decimais.
Double Determina a precisão do valor de até 15 casas decimais.
Integer ou Int Representa valores inteiros na faixa de -2.147.483.648 até 2.147.483.647.
Define valores monetários na faixa numérica de
Money
-92.233.720.368.547.758.08 até 92.233.720.368.547.758.07.
Numeric Determina a precisão do valor de casas decimais.
Real Determina a precisão do valor de até seis casas decimais.
Gera um valor único inteiro sequencial para o novo registro entre 1 e
Serial
2.147.483.647.
Smallint Representa valores inteiros na faixa de -32.768 até 32.767.
Representa um determinado horário de relógio no intervalo de tempo entre
Time
00:00:00 e 24:00:00.
Sequência de caracteres de tamanho variável que esteja limitada a 255
caracteres de comprimento. A principal diferença existente entre o tipo
Varchar (tamanho) char é que, neste caso, os espaços em branco excedentes do lado direito
da sequência de caracteres não utilizados são desprezados. O
parâmetro tamanho determina o valor máximo da sequência.
Blob Campo do tipo blob com tamanho máximo de 65535.
A partir de agora, já podemos definir uma grande variedade de campos para a construção
das tabelas utilizadas na disciplina. Em nosso banco de dados, identificado como FACULDADE,
será criado um conjunto de tabelas, conforme visualizado no modelo disposto na Figura 1.
Figura 1 Modelo de banco de dados utilizado na disciplina.
Após a instalação do PostgreSQL (passo a passo demonstrado no Apêndice 1) conforme

sugerido, existirá em seu desktop um ícone com a imagem de um elefante azul, identificado
como pgAdmin III (Figura 2).
Figura 2 Acessando a interface pgAdmin III.

Dê um duplo clique com o botão esquerdo do mouse sobre qualquer um dos ícones em
destaque. Esse procedimento exibirá a interface do pgAdmin III, como demonstrado na Figura 3.
Figura 3 Tela principal do pgAdmin III.
É necessário conectarmos no SGBD; para isso, dê um clique com o botão direito do mouse
sobre o servidor, nomeado PostgreSQL 9.0 (localhost:5432), selecionando a opção connect/
conectar ou apenas dê um duplo clique com o botão esquerdo do mouse. Na sequência, será ne-
cessário informar a senha fornecida na instalação do PostgreSQL, conforme exibido na Figura 4.
Figura 4 Conectando-se ao SGBD PostgreSQL.
Após obtermos êxito na conexão com o nosso SGBD, uma tela semelhante à Figura 5 será
exibida. Perceba que existe apenas um banco de dados (database/esquema) em nosso servidor,
chamado postgres. Selecione o banco de dados postgres e clique com o botão esquerdo do
mouse sobre o ícone Query Tool (Ctrl + E).
Figura 5 Abrindo uma sessão SQL para o banco de dados postgres.
Após a criação da sessão SQL para o banco de dados postgres, podemos criar um novo
banco de dados (schema/database): indique o nome e seus principais argumentos, conforme
exemplificado na Figura 6:
Figura 6 Tela de digitação de comandos SQL no pgAdmin III / Criação de um novo banco de dados.
Após clicar no botão/ícone Execute Query (F5), o banco de dados será criado, e a tela será
semelhante à exibida na Figura 7.

Figura 7 Visualização de objetos no pgAdmin III .
Para criar os objetos (tabelas), selecione o banco de dados FACULDADE e clique com o bo-
tão esquerdo do mouse sobre o ícone Query Tool (Ctrl + E), criando uma nova sessão SQL, agora
para o banco de dados FACULDADE. A partir daí, podemos inserir os comandos SQL a serem
aplicados para o banco de dados corrente (atual).
O primeiro objeto a ser criado para o banco de dados FACULDADE será a tabela respon-
sável pelo armazenamento de dados oriundos dos clientes, ora identificada de CLIENTES. Na
Tabela 2 podemos identificar os detalhes da estrutura da tabela CLIENTES.
Tabela 2 Clientes.
CAMPO TIPO DESCRIÇÃO
ID_CLIENTE integer Identificador do cliente (não nulo)
NM_CLIENTE varchar(10) Nome do cliente (não nulo)
SOBRENOME varchar(10) Sobrenome do cliente (não nulo)
DT_NASCIMENTO timestamp Data de nascimento do cliente
TELEFONE varchar(12) Telefone do cliente
FG_ATIVO integer Status do cliente (ativo/inativo)
Chave Primária Campo/Atributo ID_CLIENTE
O campo/atributo ID_CLIENTE será definido como chave primária, fazendo com que não
seja permitido inserir dois clientes com o mesmo código. Eventualmente, caso deseje definir
uma tabela com mais de um campo contendo registros exclusivos (únicos), basta utilizar a cláu-
sula UNIQUE.
Em seguida, será criada a tabela CLIENTES a partir da interface do pgAdmin III, utilizada
anteriormente para a criação do banco de dados FACULDADE. Escreva a sequência de instruções
exatamente como nos comandos a seguir, dentro da sessão SQL do banco de dados FACULDADE.
Para criar a tabela (essa e as próximas que serão apresentadas), clique no botão/ícone Execute
Query (F5), como demonstrado na Figura 8.
Figura 8 Tela de digitação do comando SQL no pgAdmin III / Criação da tabela CLIENTES.
Criando a tabela CLIENTES

Para a criação da tabela CLIENTES, siga os comandos a seguir:
CREATE TABLE CLIENTES(

id_cliente INTEGER,
nm_cliente VARCHAR(10) NOT NULL,
sobrenome VARCHAR(10) NOT NULL,
dt_nascimento TIMESTAMP,
telefone VARCHAR(12),
fg_ativo INTEGER,
PRIMARY KEY(ID_CLIENTE)
);
A segunda tabela a ser criada em nosso banco de dados será a tabela responsável pelo
armazenamento de dados pertinentes aos tipos de produtos vendidos, nomeada TIPOS_PRO-
DUTOS. Observe, na Tabela 3, a estrutura da tabela TIPOS_PRODUTOS:

Tabela 3 Tipos Produtos.

ID_TIPO_PRODUTO integer Identificador do tipo do produto (não nulo)
DS_TIPO_PRODUTO varchar(10) Descrição do tipo do produto (não nulo)
FG_ATIVO integer Status do tipo do produto (ativo/inativo)
Chave Primária Campo/Atributo ID_TIPO_PRODUTO
Após identificarmos com detalhes o conteúdo da tabela TIPOS_PRODUTOS, escreva a se-

quência de instruções como nos comandos a seguir, dentro da sessão SQL do banco de dados
FACULDADE. Clique no botão/ícone Execute Query (F5) para efetivar a criação da tabela, con-
forme visualizado na Figura 9.
Figura 9 Tela de digitação do comando SQL no pgAdmin III / Criação da tabela TIPOS_PRODUTOS.
Criando a tabela TIPOS_PRODUTOS

Para a criação da tabela TIPO_PRODUTOS, siga os comandos a seguir:
CREATE TABLE TIPOS_PRODUTOS(

id_tipo_produto INTEGER,
ds_tipo_produto VARCHAR(10) NOT NULL,
fg_ativo INTEGER,
PRIMARY KEY(ID_TIPO_PRODUTO)
);
A terceira tabela a ser criada em nosso banco de dados armazenará os dados referentes
aos produtos comercializados, a qual identificaremos como PRODUTOS. Observe, na Tabela 4, a
estrutura da tabela PRODUTOS.
Tabela 4 Produtos.
ID_PRODUTO integer Identificador do produto (não nulo)
ID_TIPO_PRODUTO integer Identificador do tipo do produto (não nulo)

NM_PRODUTO varchar(30) Nome do produto a ser comercializado (não nulo)
DS_PRODUTO varchar(50) Descrição do produto a ser comercializado
PRECO numeric(5,2) Preço praticado para comercialização do produto
Chave Primária Campo/Atributo ID_PRODUTO
Chave Estrangeira Campo/Atributo ID_TIPO_PRODUTO
Na sequência, insira as instruções dentro da sessão SQL do banco de dados FACULDADE.

Clique no botão/ícone Execute Query (F5) para efetivar a criação da tabela, como demonstrado
na Figura 10.
Figura 10 Tela de digitação do comando SQL no pgAdmin III / Criação da tabela PRODUTOS.
Criando a tabela PRODUTOS
CREATE TABLE PRODUTOS(

id_produto INTEGER NOT NULL,
id_tipo_produto INTEGER,
nm_produto VARCHAR(30) NOT NULL,
ds_produto VARCHAR(50),
preco NUMERIC(5,2),
fg_ativo INTEGER,
PRIMARY KEY(ID_PRODUTO),
FOREIGN KEY (ID_TIPO_PRODUTO)
REFERENCES TIPOS_PRODUTOS(ID_TIPO_PRODUTO)
);

Veja que na Tabela 4 foram indicadas uma chave primária e uma chave estrangeira. A cha-
ve primária é uma chave primária simples, ou seja, composta por apenas um campo/atributo,
ID_PRODUTO. O campo ID_TIPO_PRODUTO é a chave estrangeira, definida por meio da cláusula
FOREIGN KEY.
Para especificar por qual tabela a chave estrangeira foi criada, utilizamos REFERENCES,
permitindo que o SGBD aceite apenas valores pré-cadastrados no campo indicado da tabela
referenciada.
A tabela FUNCIONARIOS será a quarta tabela a ser criada em nosso banco de dados. Essa
tabela será responsável por armazenar dados referentes aos funcionários. Observe a estrutura
utilizada para a tabela FUNCIONARIOS:
Tabela 5 Funcionários.
ID_FUNCIONARIO integer Identificador do funcionário (não nulo)
ID_GERENTE integer Identificador do gerente
NM_FUNCIONARIO varchar(10) Nome do funcionário (não nulo)
SOBRENOME_FUNCIONARIO varchar(10) Sobrenome do funcionário (não nulo)
CARGO varchar(20) Cargo do funcionário
SALARIO numeric(6,0) Salário do funcionário
Chave Primária Campo/Atributo ID_FUNCIONARIO
Novamente, escreva a sequência de instruções dentro da sessão SQL do banco de dados

FACULDADE. Clique no botão/ícone Execute Query (F5) para efetivar a criação da tabela, como
demonstrado na Figura 11.
Figura 11 Tela de digitação do comando SQL no pgAdmin III / Criação da FUNCIONARIOS.

Criando a tabela FUNCIONARIOS
CREATE TABLE FUNCIONARIOS(

id_funcionario INTEGER,
id_gerente INTEGER,
nm_funcionario VARCHAR(10) NOT NULL,
sobrenome_funcionario VARCHAR(10) NOT NULL,
cargo VARCHAR(20),
salario NUMERIC(6,0),
fg_ativo INTEGER,
PRIMARY KEY(ID_FUNCIONARIO)
);
A quinta tabela a ser criada em nosso banco de dados armazenará dados referentes às
compras efetuadas pelos clientes. Vamos identificar esta tabela como COMPRAS. A estrutura da
tabela pode ser visualizada na Tabela 6.
Tabela 6 Compras.
ID_PRODUTO integer Identificador do produto (não nulo)
ID_CLIENTE integer Identificador do cliente (não nulo)
QUANTIDADE integer Representa a quantidade de produtos comprados
Chaves Primárias Campo/Atributo ID_PRODUTO e ID_CLIENTE
Chaves Estrangeiras Campo/Atributo ID_ PRODUTO e ID_CLIENTE
Em seguida, para criar a tabela definitivamente, insira as instruções dentro da sessão SQL
do banco de dados FACULDADE. Clique no botão/ícone Execute Query (F5), como demonstrado
na Figura 12.
Figura 12 Tela de digitação do comando SQL no pgAdmin III / Criação da COMPRAS.

Criando a tabela COMPRAS
CREATE TABLE COMPRAS(

id_produto INTEGER,
id_cliente INTEGER,
quantidade INTEGER,
fg_ativo INTEGER,
FOREIGN KEY(ID_PRODUTO) REFERENCES PRODUTOS(ID_PRODUTO),
FOREIGN KEY(ID_CLIENTE) REFERENCES CLIENTES(ID_CLIENTE),
PRIMARY KEY(ID_PRODUTO, ID_CLIENTE)
);
Nessa tabela foi indicada uma chave primária composta (constituída por dois campos/
atributos), em que as mesmas também são chaves estrangeiras. A chave primária é uma chave
composta pelos campos ID_PRODUTO e ID_CLIENTE. Os campos ID_PRODUTO e ID_CLIENTE são
chaves estrangeiras, definidas pela cláusula FOREIGN KEY.
A palavra-chave REFERENCES é utilizada para indicar que uma referência (vínculo) foi cria-
da, fazendo com que o SGBD somente aceite valores previamente cadastrados no campo indi-
cado da tabela referenciada.
A tabela GRADES_SALARIOS é a sexta e última tabela pertinente ao nosso banco de dados
FACULDADE. Essa tabela armazenará informação dos limites salariais mínimos e máximos. Ob-
serve, na Tabela 7, a estrutura da tabela GRADES_SALARIOS:
Tabela 7 Grades Salários.

ID_SALARIO integer Identificador do salário (não nulo)
SALARIO_MAXIMO number(6,0) Armazena valor máximo do salário
SALARIO_MINIMO number(6,0) Armazena valor mínimo do salário
Chave Primária Campo/Atributo ID_SALARIO
Para finalizar a criação dos objetos (tabelas), escreva a sequência de instruções dentro
da sessão SQL do banco de dados FACULDADE. Clique no botão/ícone Execute Query (F5) para
consolidar a criação da tabela, como demonstrado na Figura 13.
Figura 13 Tela de digitação do comando SQL no pgAdmin III / Criação da GRADES_SALARIOS.

Criando a tabela GRADES_SALARIOS
CREATE TABLE GRADES_SALARIOS(

id_salario INTEGER,
salario_maximo NUMERIC(6,0),
salario_minimo NUMERIC(6,0),
fg_ativo INTEGER,
PRIMARY KEY(ID_SALARIO)
);
Atente-se para as seguintes observações:

• Os campos que fazem parte da chave primária (PRIMARY KEY) não podem ficar vazios,
então coloca-se NOT NULL em sua declaração. Talvez o SGBD faça isso automaticamen-
te para você.
• No final de cada linha do comando CREATE TABLE, coloca-se uma "," (vírgula).
• A chave estrangeira (FOREIGN KEY) não está escrita errada, é IGN e não ING.
Na unidade anterior, aprendemos a importância de utilizarmos de maneira adequada as
regras de integridade de entidades e integridade referencial em um banco de dados relacional.
Atualmente, a linguagem SQL dá suporte à implementação de ambas as regras. Um exemplo é
a tabela FUNCIONARIOS, em que a regra de integridade é aplicada, automaticamente, quando
criamos a chave primária PRIMARY KEY (ID_FUNCIONARIO). É possível identificarmos também,
na tabela COMPRAS, a aplicação da integridade referencial por meio da criação das duas chaves
estrangeiras: FOREIGN KEY(ID_CLIENTE) REFERENCES CLIENTES e FOREIGN KEY(ID_PRODUTO)
REFERENCES PRODUTOS.
Quando definimos uma restrição de chave estrangeira, estamos certificando que:
• Não é possível excluir um produto da respectiva tabela se pelo menos uma tupla da
tabela COMPRAS referenciar esse produto.
• Entretanto, se uma alteração for realizada em produtos, essa alteração refletirá, auto-
maticamente, em qualquer referência desse atributo na tabela COMPRAS. Dessa ma-
neira, essa restrição impossibilita a existência de um valor para o campo ID_PRODUTO,
na tabela COMPRAS, que aponte para um valor de ID_PRODUTO inexistente da tabela
PRODUTOS.
A SQL ANSI dá suporte à utilização das cláusulas ON DELETE e ON UPDATE para cobrir as
funções de CASCADE, SET NULL ou SET DEFAULT, garantindo, assim, a preservação da integrida-
de referencial.
Além da chave primária (PRIMARY KEY) e da chave estrangeira (FOREIGN KEY), podemos
definir as seguintes restrições a partir do padrão ANSI, aplicadas sempre que uma tupla/linha for
inserida, atualizada ou removida em uma determinada tabela:
• NOT NULL: certifica que valores nulos não sejam aceitos para a coluna. Essa restrição
pode ser especificada apenas para a coluna, não para a tabela.
• UNIQUE: garante exclusividade de valor a uma coluna ou a um conjunto de colunas. A
restrição UNIQUE permite a entrada de valores nulos, exceto se você definir, simultane-
amente, a restrição NOT NULL.
• CHECK: determina uma condição que cada tupla/linha deverá satisfazer para efetiva-
mente ser inserida ou alterada.

Quando se cria uma tabela, o PostgreSQL, automaticamente, cria o índice para cada cha-
ve primária (PRIMARY KEY). Contudo, existem situações em que se faz necessária a criação de
outro índice para que o SGBD possa realizar pesquisas no banco de dados mais rapidamente. É
o caso, por exemplo, de quando se cria um índice para a coluna NM_FUNCIONARIO na tabela
FUNCIONARIOS, pois, certamente, serão realizadas pesquisas pelo nome dos funcionários. Va-
mos explorar, em detalhes e em um tópico exclusivo, a criação e gerenciamento de índices em
tabelas no PostgreSQL.
8. ESTRUTURA DA LINGUAGEM SQL – DML

A linguagem DML é a parte da linguagem SQL utilizada para manipular os dados em um
banco de dados. A manipulação dos dados refere-se às quatro operações básicas possíveis: in-
serir novos dados, alterar dados existentes, pesquisar os dados existentes no banco de dados e
apagar os dados. Os comandos responsáveis por essas quatro operações são, respectivamente:
INSERT, UPDATE, SELECT e DELETE.
Inserir novos dados – INSERT

A instrução INSERT é responsável por inserir novas tuplas/linhas (registros) nas tabelas
existentes no banco de dados. Sua sintaxe é bastante simples, como demonstrado a seguir:

INSERT INTO <TABELA> (CAMPO1, CAMPO2, …, CAMPOn
VALUES (VALOR1, VALOR2, …, VALORn);
Cada valor informado no comando INSERT deve ser do mesmo tipo do campo respectivo,
ou seja, se o primeiro campo do comando for do tipo integer, o primeiro valor deverá ser do tipo
integer. Se o segundo campo for do tipo date, o segundo valor também deverá ser do tipo date
e, assim, sucessivamente. Se essa regra não for obedecida, o SGBD emitirá uma mensagem de
erro e não efetuará a inserção. Podemos tornar as operações permanentes usando a instrução
COMMIT e/ou desfazê-las com a instrução ROLLBACK.
Após a exposição de alguns detalhes sobre a instrução INSERT, podemos adicionar algu-
mas tuplas/linhas para as tabelas CLIENTES, TIPOS_PRODUTOS, PRODUTOS, COMPRAS, FUN-
CIONARIOS e GRADES_SALARIOS .
Exemplo:
INSERT INTO CLIENTES (ID_CLIENTE, NM_CLIENTE, SOBRENOME, DT_NASCIMENTO,

TELEFONE, FG_ATIVO)
VALUES (1, 'João', 'Queiroz', '01-01-1965', '800-555-1211', 1);

TELEFONE, FG_ATIVO)
VALUES (2, 'Silvia', 'Mendes', '05-02-1968', '800-555-1212', 1);

TELEFONE, FG_ATIVO)
VALUES (3, 'Marcelo', 'Ribeiro', '16-03-1971', '800-555-1213', 1);

TELEFONE, FG_ATIVO)
VALUES (4, 'Henrique', 'Figueira', NULL, '800-555-1214', 1);
TELEFONE, FG_ATIVO)
VALUES (5, 'Dolores', 'Silva', '20-05-1970', NULL, 1);

TELEFONE, FG_ATIVO)
VALUES (6, 'Frederico', 'Vaz', '01-01-1970', '800-555-1215', 1);
INSERT INTO TIPOS_PRODUTOS (ID_TIPO_PRODUTO, DS_TIPO_PRODUTO, FG_ATIVO)

VALUES (1, 'Livro', 1);

VALUES (2, 'Vídeo', 1);

VALUES (3, 'DVD', 1);

VALUES (4, 'CD', 1);

VALUES (5, 'Revista', 1);
INSERT INTO PRODUTOS(ID_PRODUTO, ID_TIPO_PRODUTO, NM_PRODUTO, DS_

PRODUTO, PRECO, FG_ATIVO)
VALUES (1, 1, 'Ciência Moderna', 'Uma descrição da ciência moderna',
19.95, 1);

VALUES (2, 1, 'Química', 'Introdução à Química', 30, 1);

VALUES (3, 2, 'Supernova', 'Uma estrela explosiva', 25.99, 1);

VALUES (4, 2, 'Tanque de Guerra', 'Filme de ação sobre uma possível
guerra', 13.95,1 );
INSERT INTO COMPRAS (ID_CLIENTE, ID_PRODUTO, QUANTIDADE, FG_ATIVO)

VALUES (1, 1, 1, 1);

VALUES (2, 1, 3, 1);

VALUES (1, 4, 1, 1);

VALUES (2, 2, 1, 1);

VALUES (1, 3, 1, 1);
INSERT INTO FUNCIONARIOS (ID_FUNCIONARIO, ID_GERENTE, NM_FUNCIONARIO,

SOBRENOME_FUNCIONARIO, CARGO, SALARIO, FG_ATIVO)
VALUES (1, NULL, 'Jaime', 'Tenório', 'Diretor Executivo', 800000, 1);


VALUES (2, 1, 'Rubens', 'Cardoso', 'Gerente de Vendas', 600000, 1);

VALUES (3, 2, 'Frederico', 'Munhoz', 'Vendedor', 150000,1 );

VALUES (4, 2, 'Susana', 'Coimbra', 'Vendedor', 500000,1 );
INSERT INTO GRADES_SALARIOS (ID_SALARIO, SALARIO_MINIMO, SALARIO_MAXIMO,

FG_ATIVO)
VALUES (1, 1, 25000, 1);

FG_ATIVO)
VALUES (2, 250001, 500000, 1);

FG_ATIVO)
VALUES (3, 500001, 750000, 1);

FG_ATIVO)
VALUES (4, 750001, 999999, 1);
Talvez você tenha achado estranho o campo/atributo DT_NASCIMENTO, existente na ta-

bela CLIENTES, receber uma data em um formato não convencional e entre aspas, como se fosse
um texto. A explicação é simples: quando criamos a tabela CLIENTES, definimos o campo/atribu-
to DT_NASCIMENTO com o tipo timestamp, que armazena datas no formato DD-MM-AAAA, ou
seja, ano com quatro dígitos, mês e dia do mês com dois dígitos. Quanto às aspas, o PostgreSQL
converte, automaticamente, o texto, que está no formato de data e hora, para uma data. Deste
modo, sempre que precisar inserir uma data, coloque como instrução um texto, seguindo o
formato de data especificado, de acordo com o tipo de dado utilizado na construção da tabela.
Modificar registros (Alterar dados existentes) – UPDATE

A instrução UPDATE é utilizada para alterar tuplas/linhas existentes em tabelas do banco
de dados. É fundamental que você não altere os valores de campos que façam parte da chave
primária, pois erros graves de inconsistência podem ocorrer. Em uma instrução UPDATE, pode-
mos especificar as seguintes informações:
• A tabela que contém as tuplas/linhas a serem alteradas.
• Uma cláusula WHERE, especificando as tuplas/linhas a serem alteradas.
• Uma lista de nomes de colunas, junto com seus novos valores, especificado com a cláu-
sula SET, conforme podemos identificar na sintaxe a seguir:
Sintaxe
UPDATE <TABELA> SET
CAMPO1 = VALOR1,
CAMPO2 = VALOR2,
(...)
CAMPOn = VALORn
WHERE <CONDIÇÃO LÓGICA>
Como exemplo, atualizaremos o sobrenome do cliente cujo ID_CLIENTE corresponde ao Nú-

mero 2 para "Queiroz". Cuidado para não se esquecer de adicionar a cláusula WHERE, senão todas
as tuplas/linhas serão atualizadas. Caso uma alteração indesejada ocorra, ROLLBACK poderá ser acio-
nado para desfazer as alterações feitas nas tuplas/linhas (se você estiver utilizando uma transação).
Tabela 8 Identificação Clientes
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
2 Silvia Mendes 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Exemplo:
UPDATE CLIENTES
SET SOBRENOME = 'Queiroz'
WHERE ID_CLIENTE = 2;
Pesquisar dados existentes – SELECT

SELECT é uma instrução utilizada para recuperar informações das tabelas do banco de
dados. Em sua forma mais simples, são especificadas a tabela e as colunas (atributos) das quais
se deseja extrair informação.
Para exemplificar o uso da instrução SELECT, serão recuperada as colunas ID_CLIENTE,
NM_CLIENTE, SOBRENOME, DT_NASCIMENTO e TELEFONE da tabela CLIENTES.
SELECT id_cliente,
nm_cliente,
sobrenome,
dt_nascimento,
telefone
FROM clientes;
A seguir, podemos visualizar as tuplas/linhas resultantes da consulta (SELECT) realizada.

Independentemente do número de colunas (atributos) existentes na tabela CLIENTES, solicita-
mos apenas, em nossa consulta, os valores correspondentes às colunas ID_CLIENTE, NM_CLIEN-
TE, SOBRENOME, DT_NASCIMENTO e TELEFONE.
Tabela 9 Tabela I da consulta SELECT.

ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE
1 João Queiroz 01/01/1965 00:00 800-555-1211
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213
4 Henrique Figueira 800-555-1214
5 Dolores Silva 20/05/1970 00:00
6 Frederico Vaz 01/01/1970 00:00 800-555-1215
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212

Outra possibilidade de utilização da instrução SELECT diz respeito à recuperação de todas

as colunas (atributos) de uma determinada tabela.
Utilizando o caractere especial asterisco (*), podemos, por exemplo, recuperar todas as
colunas (atributos) da tabela CLIENTES.
SELECT *
FROM clientes;
Tabela 10 Tabela II da consulta SELECT.

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
Ainda é permitido, utilizando a instrução SELECT, especificar as tuplas/linhas a serem re-

cuperadas por meio da cláusula WHERE. Mesmo que o SGBD PostgreSQL possua a capacidade
de armazenamento de uma grande quantidade de tuplas/linhas em uma tabela (*), talvez você
esteja interessado apenas em um subconjunto muito pequeno de tuplas/linhas.
Para exemplificar a mesclagem da instrução SELECT com a cláusula WHERE, utilizaremos
a cláusula WHERE para recuperar a tupla/linha da tabela CLIENTES, em que a coluna (atributo)
ID_CLIENTE seja equivalente ao Número 2.
SELECT *
FROM clientes
WHERE id_cliente = 2;
Tabela 11 Tabela da consulta SELECT e WHERE.

2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
Apagar registro – DELETE

A instrução DELETE é responsável por remover as tuplas/linhas de uma determinada tabe-
la no banco de dados. A cláusula WHERE possui função semelhante à instrução UPDATE, isto é,
limita as tuplas/linhas que se deseja excluir (caso contrário, todas as tuplas/linhas serão excluí-
das da tabela). Sua sintaxe é muito simples, conforme mostrado a seguir:
DELETE FROM <TABELA>

WHERE <CONDIÇÃO LÓGICA>
Vamos remover o cliente armazenado na tabela CLIENTES, em que o identificador do clien-

te (ID_CLIENTE) corresponda ao Número 3. Não se esqueça de incluir a cláusula WHERE, senão
todas as tuplas/linhas serão removidas de sua tabela.
Tabela 12 Tabela da consulta DELETE e WHERE.

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
2 Silvia Mendes 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Exemplo:
DELETE
FROM clientes
WHERE id_cliente = 3;
Observe que serão removidos todos os registros (tuplas/linhas) cujo resultado da condi-
ção lógica for verdadeiro (cláusula WHERE).
Cálculos Aritméticos
A maioria dos SGBDs permite a realização de cálculos em instruções SQL usando expres-
sões aritméticas, as quais consistem em dois operandos (números ou datas) e um operador
aritmético.
Os quatro operadores aritméticos são:
Quadro 2 Operadores Aritméticos.
OPERADOR DESCRIÇÃO
+ Adição
- Subtração
* Multiplicação
/ Divisão
Nos exemplos a seguir, você verá a instrução proposta e, logo após, o resultado da execução.
Como primeiro exemplo do uso de cálculos em instruções SQL, utilizaremos o operador
de multiplicação (*) para calcular 2 multiplicado por 6. Os números 2 e 6 são os operandos.
Observe:
SELECT 2 * 6;
?column?
12
As regras normais de precedência de operador aritmético se aplicam na linguagem SQL.

Multiplicação e divisão são efetuadas primeiro, seguidas pela adição e subtração.
Por exemplo, a expressão 10 * 12 / 3 – 1 é executada usando a instrução SELECT.
SELECT 10 * 12 / 3 - 1;

?column?
39
É possível utilizarmos parênteses () para especificar a ordem de execução dos operadores.

No exemplo a seguir, os parênteses são usados para efetuar primeiro o cálculo de 12 / 3 – 1, cujo
resultado será, então, multiplicado por 10.
SELECT 10 * (12 / 3 - 1);
?column?
30
Além dos cálculos aritméticos efetuados nos exemplos anteriores, é permitido utilizar
operadores de adição e subtração com datas, como adicionar um número, representando um
determinado número de dias a uma data.
Para exemplificar, somaremos dois dias a 25 de julho de 2011, exibindo a data resultante:
SELECT DATE('25-JUL-2011') + 2;
?column?
27/07/2011
Nesse outro exemplo, subtrairemos três dias de 02 de agosto de 2011.
SELECT DATE('02/08/2011') - 3;
?column?
30/07/2011
Agora, subtrairemos uma data de outra, produzindo o número de dias entre elas. Para
isso, subtrairemos 01 de janeiro de 2011 de 31 de maio de 2011.
SELECT DATE('31/05/2011') - DATE('01/01/2011');
?column?
150
É possível também utilizar valores armazenados em colunas na realização dos cálculos

aritméticos. Ou seja, os operandos não precisam ser números literais ou datas; podem ser ope-
randos extraídos de colunas de uma determinada tabela.
Como exemplo, utilizaremos as colunas NM_PRODUTO e PRECO recuperadas da tabela
PRODUTOS, em que serão acrescidos R$ 2,00 aos valores pertinentes à coluna PRECO:
SELECT nm_produto,
preco + 2.00
FROM produtos;
nm_produto ?column?
Ciência Moderna 21.95
Química 32.00
Supernova 27.99
Tanque de Guerra 15.95
Como segundo exemplo, combinaremos mais de um operador em uma expressão. Os va-

lores correspondentes à coluna PRECO serão multiplicados por 3 e, então, 1 é somado ao valor
resultante:
SELECT nm_produto,
preco * 3 + 1
FROM produtos;
nm_produto ?column?
Ciência Moderna 60.85
Química 91.00
Supernova 78.97
Tanque de Guerra 42.85
Usando apelidos (alias) de coluna

Não estamos limitados a usar o cabeçalho padrão gerado pelos SGBDs. É possível fornecer
o seu próprio cabeçalho, usando um apelido (alias). No exemplo a seguir, a expressão PRECO *
2.00 recebe o apelido DOBRO_PREÇO. Veja:
SELECT nm_produto,
preco,
preco * 2 DOBRO_PREÇO
FROM produtos;
nm_produto preco dobro_preço

Ciência Moderna 19.95 39.90
Química 30.00 60.00
Supernova 25.99 51.98
Tanque de Guerra 13.95 27.90
Para preservar a caixa do texto (maiúsculo e minúsculo) e usar espaços em nomes com-
postos do seu nome alternativo (apelido), basta envolvê-lo entre aspas duplas, conforme o
exemplo a seguir:
SELECT nm_produto,
preco,
preco * 2 "DoBrO dO PrEço"
FROM produtos;
nm_produto preco DoBrO dO PrEço

Ciência Moderna 19.95 39.90
Química 30.00 60.00

nm_produto preco DoBrO dO PrEço

Supernova 25.99 51.98
Tanque de Guerra 13.95 27.90
A palavra-chave AS antes do nome alternativo (apelido) é opcional, conforme podemos

visualizar no exemplo a seguir:
SELECT 10 * (12 / 3 - 1) AS "Resultado da Expressão";
Resultado da Expressão
30
Concatenação entre Colunas

A concatenação permite combinarmos os valores de colunas, criando, assim, uma saída
mais amigável. O operador utilizado para realizar a concatenação entre colunas é o pipe duplo
||. Na tabela CLIENTES, as colunas NM_CLIENTE e SOBRENOME contêm o nome do cliente. Não
seria ideal combinar as duas colunas a fim de apresentar o nome completo do cliente? O exem-
plo a seguir demonstra essa facilidade, explorando juntamente o uso de um nome alternativo
para a coluna resultante:
SELECT nm_cliente || ' ' || sobrenome AS "Nome completo dos Clientes"

FROM clientes;
Nome completo dos Clientes

João Queiroz
Marcelo Ribeiro
Henrique Figueira
Dolores Silva
Frederico Vaz
Silvia Queiroz
Valores Nulos
Como podemos identificar um valor desconhecido (valor nulo) no banco de dados? Um
valor nulo não é uma string em branco, e sim um valor único cujo significado do valor da coluna
é desconhecido. Observe o exemplo a seguir: o cliente correspondente ao Número 4 tem um
valor nulo na coluna DT_NASCIMENTO, e o cliente identificado com o Número 5 tem um valor
nulo na coluna TELEFONE. Vamos consultar novamente a tabela CLIENTES para constatar essa
afirmativa:
SELECT *
FROM clientes;

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1

6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
Para verificar a existência de valores nulos, utilizamos IS NULL. Na instrução SELECT, a se-
guir, o cliente correspondente ao Número 4 é recuperado, pois seu valor da DT_NASCIMENTO é
um valor nulo:
SELECT id_cliente,
nm_cliente,
sobrenome,
dt_nascimento
FROM clientes
WHERE dt_nascimento IS NULL;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO

4 Henrique Figueira
Em outro exemplo, o cliente cujo número equivale a 5 é recuperado, pois seu valor perti-
nente à coluna TELEFONE também corresponde a um valor nulo:
SELECT id_cliente,
nm_cliente,
sobrenome,
telefone
FROM clientes
WHERE telefone IS NULL;
ID_CLIENTE NM_CLIENTE SOBRENOME TELEFONE

5 Dolores Silva
Exibindo tuplas/linhas distintas

Antes de qualquer coisa, listaremos os clientes que efetuaram compras em nossa loja vir-
tual, constituída a partir do esquema (database) identificado de FACULDADE, exibindo apenas a
coluna ID_CLIENTE da tabela COMPRAS.
SELECT id_cliente
FROM compras;
ID_CLIENTE
1
2
1
2
1
É possível identificar que alguns clientes fizeram mais de uma compra e, portanto, apare-
cem duplicados.

Como eliminar as tuplas/linhas duplicadas que contêm a mesma identificação? DISTINCT

é utilizado para suprimir as tuplas/linhas duplicadas. Para exemplificar a utilização do DISTINCT,
repetiremos a consulta anterior; porém, agora, incluiremos o comando DISTINCT.
SELECT DISTINCT id_cliente

FROM compras;
ID_CLIENTE
1
2
Comparando Valores
Para explorarmos o uso dos operadores de comparação, citaremos os mais usuais no Qua-
dro 3:
Quadro 3 Operadores de Comparação.
= Igual
<> ou != Diferente
< Menor que
> Maior que
<= Menor ou igual a
>= Maior ou igual a
ANY Compara um valor com qualquer valor em uma lista
SOME Idêntico ao operador ANY (você deve usar ANY "mais legível")
ALL Compara um valor com todos os valores em uma lista
Como primeiro exemplo, podemos recuperar as tuplas/linhas da tabela CLIENTES, cujo

valor correspondente à coluna ID_CLIENTE seja diferente do número 2. Observe:
SELECT *
FROM clientes
WHERE id_cliente <> 2;

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Outro exemplo é recuperarmos as colunas ID_PRODUTO e NM_PRODUTO da tabela PRO-

DUTOS, em que o valor correspondente à coluna ID_PRODUTO seja maior do que o Número 2.
SELECT id_produto, nm_produto

FROM produtos
WHERE id_produto > 2;
ID_PRODUTO NM_PRODUTO
3 Supernova
4 Tanque de Guerra
No próximo exemplo, o operador <= (menor ou igual a) é utilizado para recuperar os pro-
dutos da tabela PRODUTOS, cujos valores pertinentes à coluna ID_PRODUTO sejam <= (menor
ou igual a) ao Número 3.

FROM produtos
WHERE id_produto <= 3;
ID_PRODUTO NM_PRODUTO
1 Ciência Moderna
2 Química
3 Supernova
Agora, o operador ANY será utilizado em uma cláusula WHERE para comparar um valor
com qualquer um dos valores de uma lista. Como pré-requisito, devemos inserir um operador,
=, <>, <, >, <= ou >=, antes de ANY. Veja como recuperar as tuplas/linhas da tabela CLIENTES,
onde os valores correspondentes à coluna ID_CLIENTE sejam maiores do que qualquer um dos
valores 2, 3 ou 4:
SELECT *
FROM clientes
WHERE id_cliente > ANY (SELECT id_cliente
FROM clientes
WHERE id_cliente = 2
OR id_cliente = 3
OR id_cliente = 4);
Usamos uma subconsulta (subquery) para recuperar a lista de valores pertinentes aos
identificadores dos clientes.

3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
O operador ALL é utilizado na cláusula WHERE para comparar um determinado valor com
todos os valores de uma lista. Semelhante ao ANY, é necessário inserir um operador (=, <>, <, >,
<= ou >=) antes do ALL. Recuperaremos as tuplas/linhas da tabela CLIENTES, onde o valor asso-
ciado à coluna ID_CLIENTE seja maior do que os valores 2, 3 ou 4:
SELECT *
FROM clientes
WHERE id_cliente > ALL (SELECT id_cliente
FROM clientes
WHERE id_cliente = 2
OR id_cliente = 3
OR id_cliente = 4);

Idêntico ao exemplo anterior, lançamos uso de uma subconsulta (subquery) a fim de re-
cuperar uma lista de valores, os quais serão utilizados para comparar os identificadores dos
clientes.

5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Usando os Operadores SQL

Ao utilizarmos os operadores SQL, temos a possibilidade de limitar as tuplas/linhas com
base na correspondência de padrão de strings, listas de valores, intervalos de valores e até mes-
mo valores nulos. A seguir, detalhamos alguns dos operadores SQL mais utilizados:
Quadro 4 Operadores SQL.
LIKE Corresponde a padrões em strings
IN Corresponde a listas de valores
BETWEEN Corresponde a um intervalo de valores
IS NULL Corresponde a valores nulos
Existe também a possibilidade de utilizarmos NOT para inverter o significado de um deter-

minado operador, por exemplo: NOT LIKE, NOT IN, NOT BETWEEN e IS NOT NULL.
O uso do operador LIKE em uma cláusula WHERE é implementado para procurar um pa-
drão em uma string. Os padrões são especificados mediante a combinação de caracteres nor-
mais e os dois caracteres considerados curingas:
• Sublinhado ( _ ): corresponde a um caractere em uma posição específica.
• Porcentagem ( % ): corresponde a qualquer número de caracteres a partir da posição
especificada.
Exemplo de uso do padrão:
'_o%'
De acordo com o exemplo:

• O sublinhado corresponde a qualquer caractere na primeira posição.
• O o corresponde a um caractere o, na segunda posição.
• Porcentagem corresponde a todos os caracteres após o caractere o.
Para exemplificar o uso do operador LIKE, procuraremos o padrão '_o%' na coluna NM_
CLIENTE, da tabela CLIENTES:
SELECT *
FROM clientes
WHERE nm_cliente LIKE '_o%';

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
5 Dolores Silva 20/05/1970 00:00 1
Se, eventualmente, for necessário procurar os caracteres de sublinhado ou porcentagem

reais em uma string, devemos utilizar a opção ESCAPE para identificá-los.
Exemplo:
%\\%%
O caractere de escape (barra invertida) diz ao banco de dados como diferenciar os ca-
racteres a serem pesquisados dos caracteres curingas. O primeiro caractere % é tratado como
curinga, correspondendo a qualquer número de caracteres; o segundo % é tratado como um
caractere real a ser procurado; e, por fim, o terceiro caractere % é tratado como curinga, corres-
pondendo a qualquer número de caracteres.
Antes mesmo de aplicarmos um exemplo pertinente ao uso do caractere de escape, cria-
remos uma nova tabela em nosso banco de dados e, na sequência, serão inseridos alguns regis-
tros para essa tabela. Observe:
CREATE TABLE promocao(

id_promocao INTEGER,
nome VARCHAR NOT NULL,
duracao VARCHAR,
PRIMARY KEY(id_promocao));
INSERT INTO promocao(id_promocao, nome, duracao)

VALUES
(1, '10%', '9 dias'),
(2, '15%', '8 dias'),
(3, '20%', '7 dias'),
(4, '25%', '6 dias'),
(5, '30%', '5 dias'),
(6, '35%', '4 dias'),
(7, '40%', '3 dias'),
(8, '45%', '2 dias'),
(9, '50%', '1 dia');
Agora, com a estrutura pronta, podemos utilizar o caractere de escape para procurar o
padrão '%\\%%' na coluna NOME, da tabela PROMOCAO:
SELECT *
FROM promocao
WHERE nome LIKE '%\\%%';
ID_PROMOCAO NOME DURACAO

1 10% 9 dias
2 15% 8 dias
3 20% 7 dias
4 25% 6 dias
5 30% 5 dias
6 35% 4 dias
7 40% 3 dias
8 45% 2 dias
9 50% 1 dia

Para recuperar tuplas/linhas cujo valor da coluna esteja em uma lista de valores, utiliza-
mos o operador IN em uma cláusula WHERE. Por exemplo, podemos recuperar as tuplas/linhas
da tabela CLIENTES, em que os valores associados à coluna ID_CLIENTE corresponda aos Núme-
ros 2, 3 ou 5:
SELECT *
FROM clientes
WHERE id_cliente IN (2, 3, 5);

2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
O operador NOT permite-nos inverter a consulta, ou seja, usando o NOT IN recuperamos

as tuplas/linhas não recuperadas por IN, no exemplo anterior:
SELECT *
FROM clientes
WHERE id_cliente NOT IN (2, 3, 5);

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Devemos observar que NOT IN retornará falso se o valor que estiver na lista for nulo. O
próximo exemplo não recupera nenhuma tupla/linha, pois o valor nulo está incluído na lista:
SELECT *
FROM clientes
WHERE id_cliente NOT IN (2, 3, 5, NULL);
O operador BETWEEN também é utilizado em uma cláusula WHERE, cujo objetivo é recu-
perar as tuplas/linhas onde o valor vinculado à coluna encontra-se em um determinado inter-
valo. O intervalo inclui valores das duas extremidades. Para exemplificar o uso do operador BE-
TWEEN, recuperaremos as tuplas/linhas da tabela CLIENTES, onde valores da coluna ID_CLIENTE
estejam entre o intervalo de 1 a 3:
SELECT *
FROM clientes
WHERE id_cliente BETWEEN 1 AND 3;

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
Similar ao operador IN, o BETWEEN também permite realizar a forma negativa, ou seja, re-
cuperar as tuplas/linhas não recuperadas no exemplo anterior, por meio do uso de NOT BETWEEN.
SELECT *
FROM clientes
WHERE id_cliente NOT BETWEEN 1 AND 3;

5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Os operadores lógicos permitem limitar as tuplas/linhas com base em condições lógicas.

O Quadro 5 descreve os principais operadores lógicos.
Quadro 5 Operadores Lógicos.
x AND y Retorna verdadeiro quando x e y são verdadeiros
x OR y Retorna verdadeiro quando x ou y são verdadeiros
NOT x Retorna verdadeiro se x for falso e retorna falso se x for verdadeiro
Como exemplo de uso do operador AND, recuperaremos as tuplas/linhas da tabela CLIEN-

TES, onde as duas condições são verdadeiras:
• 1ª condição: valores da coluna DT_NASCIMENTO maior que 1º de janeiro de 1970.
• 2ª condição: valores da coluna ID_CLIENTE maior do que 3.
SELECT *
FROM clientes
WHERE dt_nascimento > '01/01/1970'
AND id_cliente > 3;

5 Dolores Silva 20/05/1970 00:00 1
Para exemplificar o uso do operador OR, nossa próxima consulta recuperará as tuplas/
linhas da tabela CLIENTES, onde uma das duas condições é verdadeira:
• 2ª condição: valores da coluna ID_CLIENTE maior do que 3.
SELECT *
FROM clientes
OR id_cliente > 3;

3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1

Quando você for utilizar os dois operadores, ou seja, mesclar AND e OR em uma mesma
expressão, AND terá precedência sobre OR (no caso, ter precedência significa ser executado
primeiro). Operadores de comparação terão precedência sobre AND. Caso deseje anular essa
precedência, faça uso de parênteses, o qual indicará a ordem de execução das expressões. A fim
de demonstrar o uso da mesclagem de operadores, o exemplo a seguir recupera as tuplas/linhas
da tabela CLIENTES, onde uma das três condições é verdadeira:
• 2ª condição: valores da coluna ID_CLIENTE menor que 2.
• 3ª condição: valores da coluna TELEFONE deverão possuir o número 1211 no final.
SELECT *
FROM clientes
OR id_cliente < 2
AND telefone LIKE '%1211';

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
A cláusula ORDER BY
A cláusula ORDER BY é usada para classificar as tuplas/linhas recuperadas por uma consul-
ta. Pode especificar uma ou mais colunas nas quais os dados serão classificados.
Em nosso primeiro exemplo, usaremos a cláusula ORDER BY para classificar por SOBRENO-
ME as tuplas/linhas recuperadas da tabela CLIENTES:
SELECT *
FROM clientes
ORDER BY sobrenome;

1 João Queiroz 01/01/1965 00:00 800-555-1211 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
A palavra-chave DESC pode ser utilizada para classificar as colunas em ordem decrescente, e
a palavra-chave ASC para especificar, explicitamente, uma classificação crescente (padrão/default).
No segundo exemplo, a cláusula ORDER BY é utilizada para classificar as tuplas/linhas re-
cuperadas da tabela CLIENTES por NM_CLIENTE em ordem crescente e SOBRENOME em ordem
decrescente:
SELECT *
FROM clientes
ORDER BY nm_cliente ASC, sobrenome DESC;

5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
O número da posição de coluna na cláusula ORDER BY pode ser utilizado para indicar qual
coluna deve ser classificada. Utilize 1 para classificar pela primeira coluna, 2 para classificar pela
segunda coluna, e assim sucessivamente. Para exemplificar o uso do ORDER BY posicional, a co-
luna ID_CLIENTE, que em nosso caso corresponde à primeira coluna (1), é usada para classificar
as tuplas/linhas recuperadas da tabela CLIENTES:
SELECT id_cliente, nm_cliente, sobrenome

FROM clientes
ORDER BY 1;
ID_CLIENTE NM_CLIENTE SOBRENOME

1 João Queiroz
2 Silvia Queiroz
3 Marcelo Ribeiro
4 Henrique Figueira
5 Dolores Silva
6 Frederico Vaz
Junção (Join)
Quando trabalhamos em um banco de dados normalizado, é comum manipularmos in-
formações armazenadas em diversas tabelas simultaneamente. Como exemplo, podemos citar
a necessidade de obter o nome do produto e o nome do tipo de produto. As tabelas PRODU-
TOS e TIPOS_PRODUTOS são relacionadas entre si por meio da coluna de chave estrangeira
ID_TIPO_PRODUTO. A coluna ID_TIPO_PRODUTO (chave estrangeira – foreign key) da tabela
PRODUTOS aponta para a coluna ID_TIPO_PRODUTO (chave primária – primary key) da tabela
TIPOS_PRODUTOS.
Para ilustrar melhor a necessidade de realizar uma junção entre tabelas, segmentaremos
as informações que necessitamos, recuperando nessa instrução SELECT apenas as colunas NM_
PRODUTO e ID_TIPO_PRODUTO da tabela PRODUTOS para o produto cujo identificador corres-
ponda ao Número 3:
SELECT nm_produto, id_tipo_produto

FROM produtos
WHERE id_produto = 3;
NM_PRODUTO ID_TIPO_PRODUTO
Supernova 2
Na sequência, recuperaremos a coluna DS_TIPO_PRODUTO da tabela TIPOS_PRODUTOS

para o ID_TIPO_PRODUTO equivalente ao Número 2. Observe:

SELECT ds_tipo_produto
FROM tipos_produtos
WHERE id_tipo_produto = 2;
DS_TIPO_PRODUTO
Vídeo
Agora que você entendeu a necessidade de realizar a junção de duas tabelas (PRODUTOS
e TIPOS_PRODUTOS), já estamos prontos para recuperar o nome do produto e a descrição do
tipo de produto usando apenas uma consulta, por meio de uma junção (JOIN). É simples: basta
incluirmos as duas tabelas na cláusula FROM da consulta e incluir as colunas relacionadas de
cada tabela na cláusula WHERE.
Exemplo:
FROM produtos, tipos_produtos
E na cláusula WHERE:
WHERE produtos.id_tipo_produto = tipos_produtos.id_tipo_produto

AND produtos.id_produto = 3;
A instrução SELECT da consulta:
SELECT produtos.nm_produto, tipos_produtos.ds_tipo_produto
No exemplo, podemos visualizar que a junção (JOIN) é a primeira condição da cláusula

WHERE (produtos.id_tipo_produto = tipos_produtos.id_tipo_produto). Normalmente, as duas
colunas na junção (JOIN) são chave primária (primary key) de uma tabela e uma chave estran-
geira (foreign key) de outra tabela.
Como o operador de igualdade (=) é utilizado na condição de junção (JOIN), esta junção é
nomeada de EQUIJOIN.
No exemplo, existe uma coluna ID_TIPO_PRODUTO na tabela PRODUTOS e outra na tabela
TIPOS_PRODUTOS. Dessa forma, é necessário informar ao banco de dados em qual tabela está
a coluna que se deseja utilizar. Se as colunas tivessem nomes distintos, não seria necessário in-
formar os nomes das tabelas em questão.
Como dica, aconselhamos que você inclua sempre os nomes das tabelas para tornar claro
de onde originam as colunas. Para finalizar nosso exemplo, incluímos todos os fragmentos an-
teriores em uma única consulta, evidenciando o uso de junção em uma instrução SELECT. Veja:
SELECT produtos.nm_produto,
tipos_produtos.ds_tipo_produto
AND produtos.id_produto = 3;
NM_PRODUTO DS_TIPO_PRODUTO
Supernova Vídeo
Para darmos prosseguimento aos nossos exemplos de junção entre tabelas, será necessá-
rio incluirmos mais registros na tabela PRODUTOS, conforme as instruções INSERT. Veja a seguir:
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto,

ds_produto, preco, fg_ativo)
VALUES (6, 2, 'Arquivos Z', 'Série sobre atividades misteriosas', 49.99,
1);

VALUES (7, 2, '2412: O Retorno', 'Alien O Retorno', 14.95, 1);

VALUES (8, 3, 'Força G', 'Aventuras dos heróis', 13.49, 1);

VALUES (9, 3, 'De outro planeta', 'Alienígena de outro planeta na
Terra', 12.99, 1);

VALUES (10, 4, 'Música clássica', 'O melhor da música clássica', 10.99,
1);

VALUES (11, 4, 'Pop 3', 'O melhor da música popular', 15.99, 1);

VALUES (12, 4, 'Yell criativo', 'Álbum de estréia', 14.99, 1);

VALUES (13, NULL, 'My Front Line', 'Seus maiores sucessos', 13.49, 1);
Como segundo exemplo do uso de junção entre tabelas, realizaremos a junção entre as
tabelas PRODUTOS e TIPOS_PRODUTOS, obtendo todos os produtos ordenados pela coluna
NM_PRODUTO:
SELECT produtos.nm_produto,
tipos_produtos.ds_tipo_produto
ORDER BY produtos.nm_produto;
2412: O Retorno Vídeo
Arquivos Z Vídeo
Ciência Moderna Livro
De outro planeta DVD
Força G DVD
Música clássica CD

Pop 3 CD
Química Livro
Supernova Vídeo
Tanque de Guerra Vídeo
Yell criativo CD
Observe que o produto My Front Line encontra-se ausente das tuplas/linhas resultantes.
Isso se deve ao fato de que o valor correspondente ao ID_TIPO_PRODUTO para essa tupla/linha
de produto corresponde a um valor nulo e a condição da junção (JOIN) não retorna o registro.
Como solução, é necessário utilizar uma junção externa (OUTER JOIN), recurso explorado ainda
nesse tópico.
A sintaxe de junção (JOIN) vista até o momento utiliza a sintaxe no padrão SQL/86 ANSI.
Para facilitar nossa vida quanto à realização de junção, a SQL permite utilizarmos apelidos
(alias) para as tabelas. Isso significa que podemos inserir nomes alternativos nas tabelas, por
exemplo: as tabelas PRODUTOS e TIPOS_PRODUTOS nas cláusulas SELECT e WHERE, evitando,
assim, a digitação redundante do nome das tabelas.
A consulta a seguir utiliza o apelido p para referenciar a tabela PRODUTOS e tp para refe-
renciar a tabela TIPOS_PRODUTOS.
SELECT p.nm_produto, tp.ds_tipo_produto

FROM produtos p, tipos_produtos tp
WHERE p.id_tipo_produto = tp.id_tipo_produto
ORDER BY p.nm_produto;
Arquivos Z Vídeo
Força G DVD
Pop 3 CD
Química Livro
Supernova Vídeo
Yell criativo CD
Produto Cartesiano
A ausência da condição JOIN promove a união de todas as tuplas/linhas de uma tabela
com todas as tuplas/linhas da outra tabela. Esse conjunto resultante é nomeado de produto
cartesiano.
Imagine que exista uma Tabela A contendo 50 tuplas/linhas, e uma segunda Tabela B con-
tendo 100 tuplas/linhas. Se selecionássemos as colunas das duas tabelas sem uma condição de
junção adequada (JOIN), obteríamos, como resultado, 5000 tuplas/linhas (cada linha da Tabela
A seria juntada a cada linha da Tabela B).
A fim de elucidar melhor este exemplo, utilizaremos nosso cenário (banco de dados FA-
CULDADE) para apresentar um subconjunto das tuplas/linhas de um produto cartesiano entre
as tabelas PRODUTOS e TIPOS_PRODUTOS:
SELECT p.nm_produto, tp.ds_tipo_produto

FROM produtos p, tipos_produtos tp;
Química Livro
Supernova Livro
Tanque de Guerra Livro
Arquivos Z Livro
2412: O Retorno Livro
Força G Livro
De outro planeta Livro
Música clássica Livro
Pop 3 Livro
Yell criativo Livro
My Front Line Livro
Ciência Moderna Vídeo
Química Vídeo
Supernova Vídeo
Arquivos Z Vídeo
Força G Vídeo
De outro planeta Vídeo
Música clássica Vídeo
Pop 3 Vídeo
Yell criativo Vídeo
My Front Line Vídeo
Ciência Moderna DVD
Química DVD
Supernova DVD
Tanque de Guerra DVD
Arquivos Z DVD
2412: O Retorno DVD
Força G DVD
Música clássica DVD
Pop 3 DVD
Yell criativo DVD
My Front Line DVD
Ciência Moderna CD
Química CD
Supernova CD

Tanque de Guerra CD
Arquivos Z CD
2412: O Retorno CD
Força G CD
De outro planeta CD
Pop 3 CD
Yell criativo CD
My Front Line CD
Ciência Moderna Revista
Química Revista
Supernova Revista
Tanque de Guerra Revista
Arquivos Z Revista
2412: O Retorno Revista
Força G Revista
De outro planeta Revista
Música clássica Revista
Pop 3 Revista
Yell criativo Revista
My Front Line Revista
Realizando SELECT entre várias tabelas (JOINs)

A instrução SELECT também permite selecionar atributos de diversas tabelas, desde que
mesclada com a instrução JOIN, que, por sua vez, é utilizada para conectar n tabelas.
Para exemplificar, recorreremos a uma consulta considerada complexa, a qual utilizará
quatro tabelas e que exigirá a realização de três JOINs. Essa consulta recuperará as seguintes
informações:
a) As compras realizadas por cada cliente (tabela COMPRAS).
b) O nome e o sobrenome do cliente (tabela CLIENTES).
c) O nome do produto que eles compraram (tabela PRODUTOS).
d) O nome do tipo de produto (tabela TIPOS_PRODUTOS).
Para obter essas informações, será necessário consultar as tabelas COMPRAS, CLIENTES,
PRODUTOS e TIPOS_PRODUTOS. As junções (JOINs) usarão os relacionamentos de chave estran-
geira (foreign key) entre as tabelas. Observe:
SELECT c.nm_cliente,
c.sobrenome,
p.nm_produto AS PRODUTO,
tp.ds_tipo_produto AS TIPO
FROM clientes c, compras co, produtos p, tipos_produtos tp
WHERE c.id_cliente = co.id_cliente
AND p.id_produto = co.id_produto
AND p.id_tipo_produto = tp.id_tipo_produto
NM_CLIENTE SOBRENOME PRODUTO TIPO

João Queiroz Ciência Moderna Livro
Silvia Queiroz Ciência Moderna Livro
Silvia Queiroz Química Livro
João Queiroz Supernova Vídeo
João Queiroz Tanque de Guerra Vídeo
JOIN e seus tipos

Existem dois tipos de condições de JOIN, as quais são baseadas no operador utilizado.
1) EQUIJOINS: utilizam o operador de igualdade (=).
2) NÃO EQUIJOINS: utilizam operadores que não correspondem ao operador de = (igual-
dade), por exemplo, < (menor que), > (maior que), BETWEEN, dentre outros.
a) JOINS INTERNAS (INNER): retornam uma tupla/linha somente quando as colunas
da junção (JOIN) contêm valores que satisfazem essa condição. Se uma tupla/
linha possui um valor nulo em uma das colunas na condição de junção (JOIN), ela
não é retornada.
b) JOINS EXTERNAS (OUTER): retornam uma tupla/linha mesmo quando uma das
colunas na condição de junção (JOIN) contém um valor nulo.
c) AUTOJOINS: retornam linhas unidas na mesma tabela.
A NÃO EQUIJOINS utiliza um operador que não corresponde ao de igualdade (=), na con-
dição de junção (JOIN).
Os operadores utilizados por esse tipo de junção são: diferente (<>), menor que (<), maior
que (>), menor ou igual a (<=), maior ou igual a (>=), LIKE, IN e BETWEEN.
Exemplificaremos a utilização desse tipo de junção (NÃO EQUIJOIN) obtendo, inicialmen-
te, os níveis salariais dos funcionários. Veja a seguir:
SELECT id_salario,
salario_minimo,
salario_maximo,
fg_ativo
FROM grades_salarios;
ID_SALARIO SALARIO_MINIMO SALARIO_MAXIMO FG_ATIVO

1 1 25000 1
2 250001 500000 1
3 500001 750000 1
4 750001 999999 1
A consulta a seguir exemplifica a utilização de uma NÃO EQUIJOIN, a qual recupera o salá-
rio e os níveis salariais dos funcionários. O nível salarial é determinado pelo operador BETWEEN.
SELECT f.nm_funcionario,
f.sobrenome_funcionario,
f.cargo, f.salario,
gs.id_salario
FROM funcionarios f, grades_salarios gs
WHERE f.salario BETWEEN gs.salario_minimo AND gs.salario_maximo
ORDER BY gs.id_salario;

NM_FUNCIONARIO SOBRENOME_FUNCIONARIO CARGO SALARIO ID_SALARIO

Susana Coimbra Vendedor 500000 2
Rubens Cardoso Gerente de Vendas 600000 3
Jaime Tenório Diretor Executivo 800000 4
Já a junção externa (OUTER JOIN) recupera uma tupla/linha mesmo quando uma de suas
colunas contém um valor nulo. No próximo exemplo, o produto My Front Line, cujo ID_TIPO_
PRODUTO é nulo, é recuperado por meio da junção externa.
SELECT p.nm_produto AS PRODUTO,

FROM produtos p
LEFT OUTER JOIN tipos_produtos tp ON(p.id_tipo_produto = tp.id_tipo_
produto)
PRODUTO TIPO
Arquivos Z Vídeo
Força G DVD
My Front Line
Pop 3 CD
Química Livro
Supernova Vídeo
Yell criativo CD
As junções externas (OUTER JOIN) podem ser segmentadas em dois tipos: junção externa
esquerda (LEFT OUTER JOIN) e junção externa direita (RIGHT OUTER JOIN). Sua sintaxe pode ser
compreendida como:
SELECT ...
FROM TABELA_1
...
Suponha que as tabelas sejam unidas em tabela_1.coluna_1 e tabela_2.coluna_2, e que

a tabela_1 contenha uma tupla/linha com um valor nulo na coluna_1. Então, para realizar uma
junção externa esquerda (LEFT OUTER JOIN), a instrução SQL ficaria:
LEFT OUTER JOIN tabela_2 ON (tabela_1.coluna_1 = tabela_2.coluna_2)
Por outro lado, suponha que a tabela_2 contenha uma tupla/linha com um valor nulo
na coluna_2. A instrução SQL seria modificada para realizar uma junção externa direita (RIGHT
OUTER JOIN):
RIGHT OUTER JOIN tabela_2 ON (tabela_1.coluna_1 = tabela_2.coluna_2)

Para exemplificar o uso da junção externa direita (RIGHT OUTER JOIN), a tabela TIPOS_
PRODUTOS contém um tipo de produto não referenciado na tabela PRODUTOS, ou seja, não
existem produtos do tipo REVISTA na tabela PRODUTOS. Veja:
SELECT id_tipo_produto,
ds_tipo_produto,
fg_ativo
FROM tipos_produtos;
ID_TIPO_PRODUTO DS_TIPO_PRODUTO FG_ATIVO

1 Livro 1
2 Vídeo 1
3 DVD 1
4 CD 1
5 Revista 1
Veja como recuperar uma REVISTA em uma das tabelas, PRODUTOS e TIPOS_PRODUTOS,
utilizando a instrução SQL a seguir.

FROM produtos p
RIGHT OUTER JOIN tipos_produtos tp ON(p.id_tipo_produto = tp.id_tipo_
produto)
PRODUTO TIPO
Arquivos Z Vídeo
Força G DVD
Pop 3 CD
Química Livro
Supernova Vídeo
Yell criativo CD
Revista
A autojunção (AUTOJOIN) é realizada na mesma tabela, ou seja, é uma consulta recursiva.

Nesse tipo de junção, torna-se imprescindível a utilização de apelidos (alias) distintos para iden-
tificar cada referência à tabela.
A tabela FUNCIONARIOS possui uma coluna ID_GERENTE para cada funcionário. Caso um
determinado funcionário não seja gerenciado por ninguém, o ID_GERENTE será nulo. O funcio-
nário cujo nome corresponde a Jaime é considerado o Diretor Executivo CEO (Chief Executive
Officer), tendo um valor nulo para o ID_GERENTE. Usaremos o AUTOJOIN para exibir os nomes
de cada funcionário e seu respectivo gerente:

SELECT f.nm_funcionario || ' '

|| f.sobrenome_funcionario || ' trabalha para '
|| g.nm_funcionario
FROM funcionarios f, funcionarios g
WHERE f.id_gerente = g.id_funcionario
ORDER BY f.nm_funcionario;
?column?
Frederico Munhoz trabalha para Rubens
Rubens Cardoso trabalha para Jaime
Susana Coimbra trabalha para Rubens
O padrão SQL/92 introduz as cláusulas INNER JOIN e ON para realizar uma junção interna.
A instrução SQL, a seguir, ilustra o uso do padrão SQL/92 para recuperar o nome do produto
(tabela PRODUTOS) e a descrição do tipo do produto (tabela TIPOS_PRODUTOS).

FROM produtos p
INNER JOIN tipos_produtos tp ON (p.id_tipo_produto = tp.id_tipo_produto)
PRODUTO TIPO
Arquivos Z Vídeo
Força G DVD
Pop 3 CD
Química Livro
Supernova Vídeo
Yell criativo CD
Já vimos como realizar uma consulta utilizando operadores de NÃO EQUIJOIN com a cláu-
sula ON no padrão SQL/86. Agora, traduziremos a consulta para o padrão SQL/92. Observe:
SELECT f.nm_funcionario,
f.sobrenome_funcionario,
f.cargo,
f.salario,
gs.id_salario
FROM funcionarios f
INNER JOIN grades_salarios gs ON(f.salario BETWEEN gs.salario_minimo AND
gs.salario_maximo)
ORDER BY gs.id_salario;
O padrão SQL/92 permite simplificar ainda mais a condição de JOIN com a cláusula USING.
Algumas limitações devem ser evidenciadas, como: a consulta deve usar uma EQUIJOIN, e as
colunas na EQUIJOIN devem ter o mesmo NOME. A próxima consulta implementa o uso de
USING substituindo ON, para exibir o nome do produto (tabela PRODUTOS) e seu respectivo tipo
(tabela TIPOS_PRODUTOS).

FROM produtos p
INNER JOIN tipos_produtos tp
USING(id_tipo_produto);
PRODUTO TIPO
Química Livro
Supernova Vídeo
Arquivos Z Vídeo
Força G DVD
Pop 3 CD
Yell criativo CD
Caso seja necessário exibir o ID_TIPO_PRODUTO, será imprescindível fornecer o nome da

coluna sozinho, ou seja, sem o nome ou apelido da tabela na cláusula SELECT.

tp.ds_tipo_produto AS TIPO,
id_tipo_produto
FROM produtos p
USING(id_tipo_produto);
PRODUTO TIPO ID_TIPO_PRODUTO

Ciência Moderna Livro 1
Química Livro 1
Supernova Vídeo 2
Tanque de Guerra Vídeo 2
Arquivos Z Vídeo 2
2412: O Retorno Vídeo 2
Força G DVD 3
De outro planeta DVD 3
Música clássica CD 4
Pop 3 CD 4
Yell criativo CD 4
O nome da coluna dentro da cláusula USING deverá, também, permanecer sozinho, con-
forme visualizado no exemplo a seguir, onde um erro é retornado.


tp.ds_tipo_produto AS TIPO,
id_tipo_produto
FROM produtos p
USING(p.id_tipo_produto);
Figura 14 Utilização indevida da cláusula USING.
É possível utilizar junções internas envolvendo mais de duas tabelas usando o padrão
SQL/92, conforme a consulta a seguir, a qual recupera o nome e sobrenome do cliente (tabela
CLIENTES), nome do produto (tabela PRODUTOS) e descrição do tipo de produto (tabela TIPOS_
PRODUTOS), com a identificação dos clientes e suas respectivas compras.
SELECT c.nm_cliente,
c.sobrenome,
p.nm_produto AS PRODUTO,
FROM clientes c
INNER JOIN compras co USING (id_cliente)
INNER JOIN produtos p USING (id_produto)
INNER JOIN tipos_produtos tp USING (id_tipo_produto)
NM_CLIENTE SOBRENOME PRODUTO TIPO

João Queiroz Ciência Moderna Livro
Silvia Queiroz Ciência Moderna Livro
Silvia Queiroz Química Livro
João Queiroz Supernova Vídeo
João Queiroz Tanque de Guerra Vídeo
As junções internas que fazem uso de diversas colunas também podem usufruir do padrão
SQL/92. Se uma junção (JOIN) utiliza mais de uma coluna nas duas tabelas, forneça essas colu-
nas em sua cláusula ON, utilizando, paralelamente, o operador AND.
Para exemplificar, considere duas tabelas nomeadas de TABELA_1 e TABELA_2, as quais
necessitamos juntar usando colunas chamadas de COLUNA_1 e COLUNA_2 nas duas tabelas.
Observe:
SELECT ...
FROM TABELA_1
INNER JOIN TABELA_2 ON (TABELA_1.COLUNA_1 = TABELA_2.COLUNA_2
AND TABELA_1.COLUNA_2 = TABELA_2.COLUNA_2);
Com o objetivo de simplificar nossas vidas, poderíamos acrescentar, na consulta, a cláu-

sula USING, mas somente se estivermos realizando EQUIJOIN e os nomes das colunas forem
idênticos, conforme a sintaxe a seguir.
SELECT ...
FROM TABELA_1
INNER JOIN TABELA_2
USING (COLUNA_1, COLUNA_2);
Para detalhar as junções externas, consideramos a sintaxe a seguir:
SELECT ...
FROM TABELA_1 { LEFT | RIGHT | FULL }
OUTER JOIN TABELA_2
Onde:
1) TABELA_1 e TABELA_2: são as tabelas pertinentes à junção.
2) LEFT: realiza uma JOIN externa esquerda.
3) RIGHT: realiza uma JOIN externa direita.
4) FULL: realiza uma JOIN externa completa (utiliza todas as tuplas/linhas da TABELA_1 e
TABELA_2, incluindo os valores nulos nas colunas usadas na junção).
O exemplo a seguir ilustra o uso da junção externa completa (FULL OUTER JOIN) empre-
gando o padrão SQL/92, a qual permite incluir as tuplas/linhas das tabelas unidas, inclusive
aqueles valores nulos em uma ou outra das colunas usadas na JOIN. Veja:
FROM produtos p
FULL OUTER JOIN tipos_produtos tp
USING (id_tipo_produto)
PRODUTO TIPO
Arquivos Z Vídeo
Força G DVD
My Front Line
Pop 3 CD
Química Livro
Supernova Vídeo
Yell criativo CD
Revista

O produto cartesiano, ou melhor, a junção cruzada, também pode usufruir do padrão

SQL/92 para simplificar a instrução SQL. Usando a sintaxe de junção (JOIN) SQL/92, evitamos
a produção acidental de um produto cartesiano, simplesmente ao se utilizar a cláusula ON ou
USING. Dessa maneira, para forçarmos um produto cartesiano por meio do padrão SQL/92, usa-
mos explicitamente as palavras-chave CROSS JOIN, conforme a consulta a seguir, a qual realiza
um produto cartesiano (junção cruzada) entre as tabelas TIPOS_PRODUTOS e PRODUTOS.
SELECT tp.id_tipo_produto,
tp.ds_tipo_produto,
p.nm_produto,
p.ds_produto,
p.preco
FROM tipos_produtos tp
CROSS JOIN produtos p;
ID_TIPO_PRODUTO DS_TIPO_PRODUTO NM_PRODUTO DS_PRODUTO RECO

1 Livro Ciência Moderna Uma descrição da ciência moderna 19.95
1 Livro Química Introdução à Química 30.00
1 Livro Supernova Uma estrela explosiva 25.99
1 Livro Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
1 Livro Arquivos Z Série sobre atividades misteriosas 49.99
1 Livro 2412: O Retorno Alien O Retorno 14.95
1 Livro Força G Aventuras dos heróis 13.49
1 Livro De outro planeta Alienígena de outro planeta na Terra 12.99
1 Livro Música clássica O melhor da música clássica 10.99
1 Livro Pop 3 O melhor da música popular 15.99
1 Livro Yell criativo Álbum de estréia 14.99
1 Livro My Front Line Seus maiores sucessos 13.49
2 Vídeo Ciência Moderna Uma descrição da ciência moderna 19.95
2 Vídeo Química Introdução à Química 30.00
2 Vídeo Supernova Uma estrela explosiva 25.99
2 Vídeo Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
2 Vídeo Arquivos Z Série sobre atividades misteriosas 49.99
2 Vídeo 2412: O Retorno Alien O Retorno 14.95
2 Vídeo Força G Aventuras dos heróis 13.49
2 Vídeo De outro planeta Alienígena de outro planeta na Terra 12.99
2 Vídeo Música clássica O melhor da música clássica 10.99
2 Vídeo Pop 3 O melhor da música popular 15.99
2 Vídeo Yell criativo Álbum de estréia 14.99
2 Vídeo My Front Line Seus maiores sucessos 13.49
3 DVD Ciência Moderna Uma descrição da ciência moderna 19.95
3 DVD Química Introdução à Química 30.00
3 DVD Supernova Uma estrela explosiva 25.99
3 DVD Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
3 DVD Arquivos Z Série sobre atividades misteriosas 49.99
3 DVD 2412: O Retorno Alien O Retorno 14.95
3 DVD Força G Aventuras dos heróis 13.49
3 DVD De outro planeta Alienígena de outro planeta na Terra 12.99
ID_TIPO_PRODUTO DS_TIPO_PRODUTO NM_PRODUTO DS_PRODUTO RECO

3 DVD Música clássica O melhor da música clássica 10.99
3 DVD Pop 3 O melhor da música popular 15.99
3 DVD Yell criativo Álbum de estréia 14.99
3 DVD My Front Line Seus maiores sucessos 13.49
4 CD Ciência Moderna Uma descrição da ciência moderna 19.95
4 CD Química Introdução à Química 30.00
4 CD Supernova Uma estrela explosiva 25.99
4 CD Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
4 CD Arquivos Z Série sobre atividades misteriosas 49.99
4 CD 2412: O Retorno Alien O Retorno 14.95
4 CD Força G Aventuras dos heróis 13.49
4 CD De outro planeta Alienígena de outro planeta na Terra 12.99
4 CD Música clássica O melhor da música clássica 10.99
4 CD Pop 3 O melhor da música popular 15.99
4 CD Yell criativo Álbum de estréia 14.99
4 CD My Front Line Seus maiores sucessos 13.49
5 Revista Ciência Moderna Uma descrição da ciência moderna 19.95
5 Revista Química Introdução à Química 30.00
5 Revista Supernova Uma estrela explosiva 25.99
5 Revista Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
5 Revista Arquivos Z Série sobre atividades misteriosas 49.99
5 Revista 2412: O Retorno Alien O Retorno 14.95
5 Revista Força G Aventuras dos heróis 13.49
5 Revista De outro planeta Alienígena de outro planeta na Terra 12.99
5 Revista Música clássica O melhor da música clássica 10.99
5 Revista Pop 3 O melhor da música popular 15.99
5 Revista Yell criativo Álbum de estréia 14.99
5 Revista My Front Line Seus maiores sucessos 13.49
Funções Simples - SQL

Uma função poderá aceitar zero ou mais parâmetros de entrada, retornando um parâme-
tro de saída. No PostgreSQL existem dois tipos de funções, identificadas como:
• Funções de uma única linha: operam uma tupla/linha por vez e retornam uma tupla/
linha de saída para cada tupla/linha de entrada.
Exemplo:
CONCAT(x, y)
O comando retorna uma string resultante.

• Funções de Agregação: operam sobre várias tuplas/linhas por vez e retornam uma tu-
pla/linha de saída.
Exemplo:
AVG(x)

O comando retorna a média de x, em que x pode ser uma coluna e/ou uma expressão.
As funções de uma única linha são segmentadas em cinco tipos principais, detalhadas a
seguir:
1) Funções de caractere: manipulam strings de caracteres.
2) Funções numéricas: efetuam cálculos.
3) Funções de conversão: convertem um valor de um tipo para outro.
4) Funções de data: processam data e hora.
5) Funções de expressão regular: utilizam expressões regulares para procurar dados.
As funções de caractere aceitam a entrada de caractere (coluna ou expressão). Um exem-
plo é a função de caractere ASCII(x), utilizada para obter o valor ASCII do caractere x. Veja a
seguir:
SELECT ASCII('a'),
ASCII('A'),
ASCII('z'),
ASCII('Z'),
ASCII('0'),
ASCII('9');
ASCII ASCII ASCII ASCII ASCII ASCII

97 65 122 90 48 57
Para realizar o inverso da função ASCII(x), a função CHR(x) permite obter o caractere com
o valor ASCII. Observe:
SELECT CHR(97),
CHR(65),
CHR(122),
CHR(90),
CHR(48),
CHR(57);
CHR CHR CHR CHR CHR CHR

A A z Z 0 9
A função INITCAP(x) converte a letra inicial de cada palavra de x em maiúsculas. Para

exemplificar o uso da função INITCAP(x), os registros associados à coluna DS_PRODUTO terão
sua primeira letra de cada palavra convertidas em maiúsculas. Veja:
SELECT id_produto,
INITCAP(ds_produto)
FROM produtos
ORDER BY id_produto;
ID_PRODUTO INITCAP
1 Uma Descrição Da Ciência Moderna
2 Introdução À Química
3 Uma Estrela Explosiva
4 Filme De Ação Sobre Uma Possível Guerra
ID_PRODUTO INITCAP
6 Série Sobre Atividades Misteriosas
7 Alien O Retorno
8 Aventuras Dos Heróis
9 Alienígena De Outro Planeta Na Terra
10 O Melhor Da Música Clássica
11 O Melhor Da Música Popular
12 Álbum De Estréia
13 Seus Maiores Sucessos
LENGTH(x) é uma função que obtém o número de caracteres em x. No exemplo a seguir,

observe o uso da função LENGHT(x) para obter o comprimento dos strings na coluna NM_PRO-
DUTO da tabela PRODUTOS:
SELECT nm_produto,
LENGTH(nm_produto)
FROM produtos;
NM_PRODUTO LENGTH
Ciência Moderna 15
Química 7
Supernova 9
Tanque de Guerra 16
Arquivos Z 10
2412: O Retorno 15
Força G 7
De outro planeta 16
Música clássica 15
Pop 3 5
Yell criativo 13
My Front Line 13
A função LOWER(x) converte as letras de x para minúsculas e a função UPPER(x) converte

as letras de x para maiúsculas. Para exemplificar o uso das duas funções que manipulam carac-
teres, serão convertidos os strings da coluna NM_FUNCIONARIO em maiúsculas e os strings
associados à coluna SOBRENOME_FUNCIONARIO em minúsculas.
SELECT UPPER(nm_funcionario) AS NOME,

LOWER(sobrenome_funcionario) AS SOBRENOME
FROM funcionarios;
NOME SOBRENOME
JAIME tenório
RUBENS cardoso
FREDERICO munhoz
SUSANA coimbra

As duas funções a seguir fornecem facilitadores na formatação de relatórios oriundos de

um banco de dados. A função LPAD(x, largura, string preenchimento) preenche x com espaços
à esquerda até atingir o comprimento total da string (largura). Ela permite fornecer a string de
preenchimento (parâmetro opcional). A função RPAD(x, largura, string preenchimento) preen-
che x com espaços à direita até atingir o comprimento total da string (largura). Semelhante à
função LPAD(x, largura, string preenchimento), o RPAD(x, largura, string preenchimento) tam-
bém permite fornecer a string de preenchimento (parâmetro opcional). Para exemplificar o uso
dessas duas funções, a coluna NM_PRODUTO será preenchida à direita (comprimento igual a
30 – string pontos (.)) e a coluna DS_PRODUTO será preenchida à esquerda (comprimento igual
a 50 – string (*+)):
SELECT RPAD(nm_produto, 30, '.'),

LPAD(ds_produto, 50, '*+')
FROM produtos
RPAD LPAD
Ciência Moderna............... *+*+*+*+*+*+*+*+*+Uma descrição da ciência moderna
Química....................... *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+Introdução à Química
Supernova..................... *+*+*+*+*+*+*+*+*+*+*+*+*+*+*Uma estrela explosiva
Tanque de Guerra.............. *+*+*+*+*+*Filme de ação sobre uma possível guerra
Arquivos Z.................... *+*+*+*+*+*+*+*+Série sobre atividades misteriosas
2412: O Retorno............... *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*Alien O Retorno
Força G....................... *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+Aventuras dos heróis
De outro planeta.............. *+*+*+*+*+*+*+Alienígena de outro planeta na Terra
Música clássica............... *+*+*+*+*+*+*+*+*+*+*+*O melhor da música clássica
Pop 3......................... *+*+*+*+*+*+*+*+*+*+*+*+O melhor da música popular
Yell criativo................. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+Álbum de estréia
My Front Line................. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*Seus maiores sucessos
A função LTRIM(x, string de corte) corta a esquerda de x, permitindo fornecer a string de

corte (parâmetro opcional). Caso não seja informada a string de corte, os espaços serão corta-
dos por padrão. RTRIM(x, string de corte) é o oposto da função LTRIM(x, string de corte), cortan-
do a direita de x, permitindo também fornecer a string de corte (parâmetro opcional). Caso não
seja informada a string de corte, os espaços também serão cortados por padrão.
Uma função que corta ambos os lados (DIREITO e ESQUERDO) simultaneamente é nomea-
da de TRIM(x, string de corte). Idêntica às funções LTRIM(x, string de corte) e RTRIM(x, string de
corte), TRIM(x, string de corte) também permite fornecer a string de corte (parâmetro opcional)
e, caso não seja informada a string de corte, os espaços também serão cortados por padrão em
ambos os lados.
O próximo exemplo demonstra o uso das três funções simultaneamente: LTRIM(x, string
de corte), RTRIM(x, string de corte) e TRIM(x, string de corte):
SELECT
LTRIM(' Olá pessoal, tudo joia?'),
RTRIM('Olá tudo bem!abc', 'abc'),
TRIM('x' FROM 'xxxAula de BDxxxxx');
LTRIM RTRIM BTRIM

Olá pessoal, tudo joia? Olá tudo bem! Aula de BD
Para procurar uma string qualquer e substituí-la por outra, utilizamos a função REPLACE(x,
string de busca, string substituta), onde é realizada a busca baseando-se na string de busca em
x e substituída pela string substituta. O exemplo a seguir utiliza o produto cujo ID_PRODUTO
corresponda ao Número 1 (Ciência Moderna – a string Ciência será substituído por Física). Um
detalhe importante é que não é alterada a tupla/linha real no banco de dados; somente a tupla/
linha retornada pela função é modificada. Veja a seguir:
SELECT REPLACE(nm_produto,
'Ciência',
'Física')
FROM produtos
WHERE id_produto = 1;
REPLACE
Física Moderna
Eventualmente, torna-se necessário extrair partes de uma string qualquer. A função

SUBSTR(x, início, comprimento) retorna uma substring de x que inicia na posição especificada
pelo parâmetro início. Essa função também permite fornecer um comprimento (parâmetro op-
cional) para a substring. Para ilustrar a funcionalidade da função SUBSTR(x, início, comprimen-
to), a tabela PRODUTOS será utilizada para obtermos a substring de sete caracteres a partir da
Posição 2 da coluna NM_PRODUTO.
SELECT nm_produto AS Original,

SUBSTR(nm_produto, 2, 7) AS Substring
FROM produtos
ORIGINAL SUBSTRING
Ciência Moderna iência
Química uímica
Supernova upernov
Tanque de Guerra anque d
Arquivos Z rquivos
2412: O Retorno 412: O
Força G orça G
De outro planeta e outro
Música clássica úsica c
Pop 3 op 3
Yell criativo ell cri
My Front Line y Front
É possível também fornecer qualquer expressão válida que seja avaliada como uma string.
No próximo exemplo – do uso de SUBSTR(x, início, comprimento) –, utilizaremos a função para
obter a substring DBA da string Administrador de Banco de Dados - DBA.

SELECT SUBSTR('Administrador de Banco de Dados - DBA',

34,
4);
SUBSTR
DBA
Em uma instrução SQL é possível utilizar uma combinação de funções. Por exemplo, ima-
gine que é preciso combinar as funções UPPER(x) e SUBSTR(x, início, comprimento), em que a
saída da função SUBSTR() é passada para a função UPPER(x). Veja a seguir:
SELECT nm_produto,
UPPER(SUBSTR(nm_produto, 2, 8))
FROM produtos
NM_PRODUTO UPPER
Ciência Moderna IÊNCIA M
Química UÍMICA
Supernova UPERNOVA
Tanque de Guerra ANQUE DE
Arquivos Z RQUIVOS
2412: O Retorno 412: O R
Força G ORÇA G
De outro planeta E OUTRO
Música clássica ÚSICA CL
Pop 3 OP 3
Yell criativo ELL CRIA
My Front Line Y FRONT
As funções numéricas realizam diversos cálculos, sejam esses utilizando expressões ou

valores atrelados às colunas de uma determinada tabela. A função ABS(x) permite obtermos um
valor absoluto de x, que é o número sem o sinal (positivo/negativo).
Para exemplificar o uso da função ABS(x), será subtraído 30 dos valores correspondentes
à coluna PRECO da tabela PRODUTOS.
SELECT id_produto,
preco,
preco - 30,
ABS(preco - 30)
FROM produtos;
ID_PRODUTO PRECO ?COLUMN? ABS

1 19.95 -10.05 10.05
2 30.00 0.00 0.00
3 25.99 -4.01 4.01
4 13.95 -16.05 16.05
6 49.99 19.99 19.99
7 14.95 -15.05 15.05
ID_PRODUTO PRECO ?COLUMN? ABS

8 13.49 -16.51 16.51
9 12.99 -17.01 17.01
10 10.99 -19.01 19.01
11 15.99 -14.01 14.01
12 14.99 -15.01 15.01
13 13.49 -16.51 16.51
A função identificada como CEIL(x) é oriunda, também, da família das funções numéricas,
cuja finalidade é obter o número menor inteiro, maior ou igual a x. Para ilustrar sua utilização,
a função CEIL(x) será utilizada para obter os valores absolutos de 5,8 e -5,2. O teto de 5,8 é 6,
porque corresponde ao número menor inteiro, maior do que 5,8, e o teto de -5,2 é -5, porque
-5,2 é negativo e o número menor inteiro, maior do que ele é -5.
SELECT CEIL(5.8),
CEIL(-5.2);
CEIL Ceil
6 -5
Oposto à função CEIL(x), a função FLOOR(x), por sua vez, obtém o maior número inteiro,
menor ou igual a x. Como exemplos serão utilizados os mesmos parâmetros da função anterior,
em que a função FLOOR(x) obterá o valor absoluto de 5,8 e -5,2. O piso de 5,8 é 5, porque 5 é
maior número inteiro, menor do que 5,8 e o piso de -5,2 é -6, porque -5,2 é negativo e o maior
número inteiro, menor do que este valor é -6.
SELECT FLOOR(5.8),
FLOOR(-5.2);
Floor floor
5 -6
A função MOD(x, y) obtém o resto da divisão de x por y. Essa função é frequentemente uti-
lizada para descobrir se um determinado número é par ou ímpar, ou até mesmo se um número
qualquer é múltiplo de outro. Como exemplo, a função MOD(x, y) será utilizada para obtermos
o resto da divisão, quando 8 for dividido por 3 e por 4. Acompanhe a seguir:
SELECT MOD(8, 3),

MOD(8, 4);
Mod mod
2 0
A função POWER(x, y) é uma função numérica que obtém o resultado de x elevado à po-
tência y. A função POWER(x, y) obterá 2 elevado às potências 1 e 3 como exemplo. Observe:
SELECT POWER(2, 1),

POWER(2, 3);

Power power
2 8
A função ROUND(x, [y]) é utilizada para obter o arredondamento de x com y casas deci-
mais (parâmetro opcional). Se o y for omitido, x será arredondado com zero casa decimal e se y
for negativo, x será arredondado à esquerda do ponto decimal.
Como exemplo, ROUND(x, [y]) será utilizado para obter o resultado do arredondamento
de 5,75 com zero, 1 e -1 casas decimais. Acompanhe:
SELECT ROUND(5.75),
ROUND(5.75, 1),
ROUND(5.75, -1);
Round round round

6 5.8 10
SIGN(x) é uma função cujo objetivo é obter o sinal de x. A função retorna -1 se x for nega-
tivo, retorna 1 se x for positivo e retorna 0 (zero) se x for zero. Um exemplo é o uso da função
SIGN(x) para obter o sinal dos valores -5, 5 e 0. Observe:
SELECT SIGN(-5),
SIGN(5),
SIGN(0);
Sign sign sign

-1 1 0
Para obter a raiz quadrada de um determinado número, você poderá recorrer à função
SQRT(x). Como exemplo, a função obterá a raiz quadrada de 25 e 5, respectivamente. Veja a
seguir:
SELECT SQRT(25),
SQRT(5);
SQRT SQRT
5 2.23606797749979
Percebe-se que o resultado proveniente da raiz quadrada de 5 não se encontra forma-

tado adequadamente. Para isso, a função TRUNC(x, [y]) é utilizada para obter o resultado do
truncamento do número x com y casas decimais (parâmetro opcional). Caso y seja omitido, x
será truncado com zero casa decimal. Se y for negativo, y será truncado à esquerda do ponto
decimal. Vejamos o uso da função TRUNC(x, [y]): ela realizará o truncamento de 5,75 com zero,
1 e -1 casas decimais.
SELECT TRUNC(5.75),
TRUNC(5.75, 1),
TRUNC(5.75, -1);
TRUNC TRUNC TRUNC

5 5.7 0
Agora que encerramos a apresentação e os exemplos pertinentes às funções numéricas,

podemos iniciar a exploração das funções de conversão. Para dar início às funções de conversão,
vejamos a função TO_CHAR(x, [format]), que converte x em uma string e permite fornecer o for-
mato de saída de x (parâmetro opcional). A estrutura do formato depende de x ser um número
ou uma data.
Como exemplo, a função TO_CHAR(x, [format]) realiza a conversão de um número em uma
string usando o formato 99.999.99.
SELECT TO_CHAR(12345.67,
'99,999.99');
TO_CHAR
12,345.67
O parâmetro 9 retorna dígitos na posição especificada, com um sinal negativo à esquerda

se o número for negativo. O exemplo a seguir apresenta a importância de manipularmos ade-
quadamente o parâmetro 9. Observe:
'99999.99');
TO_CHAR
12345.67
O parâmetro 0 (zero) retorna um número com zeros à esquerda e/ou à direita. O uso do
parâmetro 0 (zero) pode ser visualizado no exemplo a seguir. Observe:
'099,999.99');
TO_CHAR
012,345.67
O parâmetro . (ponto), por sua vez, retorna para a função um ponto decimal na posição
específica. Já o parâmetro , (vírgula) retorna uma vírgula também na posição especificada pela
função. Nos exemplos explorados até o momento, com a função TO_CHAR(x, [format]), utiliza-
mos um (somente o . (ponto)) ou ambos os parâmetros (. (ponto) e , (vírgula)).
A letra L também pode ser utilizada como parâmetro para a função TO_CHAR(x, [format]),
retornando o símbolo de moeda local na posição especificada. O símbolo vem da variável do
SGBD lc_monetary. No exemplo a seguir o parâmetro L é utilizado para inserir o símbolo da
moeda local. Veja:
'L99,999.99');

TO_CHAR
R$ 12,345.67
Um parâmetro muito interessante utilizado na função TO_CHAR(x, [format]) é o RN, o qual

retorna para a função o número em algarismos romanos. O RN retorna números maiúsculos e M
retorna números minúsculos. O número deve ser um valor inteiro entre o intervalo de 1 a 3999.
No próximo exemplo, a função TO_CHAR(x, [format]) é utilizada para converter o número 2011
em algarismos romanos. Acompanhe:
SELECT TO_CHAR(2011,
'RN');
TO_CHAR
MMXI
A função TO_CHAR(x, [format]) retornará uma string de caracteres # se, eventualmente,

for formatado um número contendo dígitos a mais para o formato. Por exemplo, o número
12345678.90 para o formato 99,999.99.
'99,999.99');
TO_CHAR
##,###.##
O próximo exemplo de uso da função TO_CHAR(x, [format]) converte valores de colunas

contendo números em strings, ou seja, nesse exemplo serão convertidos valores atrelados à
coluna PRECO da tabela PRODUTOS em uma string, utilizando, paralelamente, o parâmetro L
(símbolo de moeda local).
SELECT id_produto, 'O preço do produto é: ' ||

TO_CHAR(preco, 'L99.99')
FROM produtos
ID_PRODUTO ?COLUMN?
1 O preço do produto é: R$ 19.95
Com a funcionalidade exatamente inversa, a função TO_CHAR(x, [format]), TO_NUMBER(x,

[format]) converte x em um número, permitindo fornecer uma string de formato para indicar o
formato de x (parâmetro opcional). Para exemplificar o uso da função TO_NUMBER(x, [format]),
a string 970,13 será convertida em número. Veja:
SELECT TO_NUMBER('970.13',
'999.99');
TO_NUMBER
970.13
Finalizando as funções de conversão, a função CAST(x AS tipo) é utilizada para converter

x em um tipo de dado compatível, especificado por tipo. Para exemplificar o uso dessa função,
CAST(x AS tipo) será utilizada diversas vezes para realizar a conversão adequada de tipo de dado.
SELECT
CAST(12345.67 AS VARCHAR(10)),
CAST('01-12-2009' AS DATE),
CAST(12345.678 AS NUMERIC(10,2));
VARCHAR DATE NUMERIC

12345.67 01/12/2009 12345.68
As funções agregadas operam em um grupo de tuplas/linhas e retornam uma tupla/linha

de saída. Essas funções de agregação também são conhecidas como funções de grupo pelo fato
de trabalhar em grupo de tuplas/linhas. Algumas observações devem ser feitas:
• Possibilidade de utilizar funções agregadas com qualquer expressão válida, por exem-
plo, COUNT(), MAX() e MIN() com números, strings e data/hora.
• Valores nulos são ignorados pelas funções agregadas (nulo indica um valor desconhe-
cido).
• Uso da palavra DISTINCT em uma função agregada para excluir entradas duplicadas.
Para falar sobre as funções de agregação, iniciaremos pela função AVG(x), que obtém o
valor médio de x. Para ilustrar o uso dessa função, será obtido o preço médio dos produtos ca-
dastrados na tabela PRODUTOS. Acompanhe a seguir:
SELECT AVG(preco)
FROM produtos;
AVG
19.7308333333333
A função COUNT(x) também faz parte das funções agregadas; ela obtém o número de
tuplas/linhas retornadas por uma consulta. Para exemplificar, utilizaremos a função COUNT(x)
para obter o número de tuplas/linhas na tabela PRODUTOS.
SELECT COUNT(id_produto)
FROM produtos;

COUNT
12
As funções MAX(x) e MIN(x) obtêm, respectivamente, o valor máximo e mínimo de x. Para

visualizar sua aplicabilidade, o próximo exemplo mostra o valor máximo e o valor mínimo da
coluna PRECO da tabela PRODUTOS.
SELECT MAX(preco),
MIN(preco)
FROM produtos;
MAX MIN
49.99 10.99
As funções MAX(x) e MIN(x) permitem utilizar qualquer tipo de dado, inclusive strings e
datas. A função MAX(x) com strings são classificadas em ordem alfabética, com a string máxima
no final da lista e a string mínima no início. Para ilustrar essa funcionalidade, o exemplo a seguir
obtém as strings máxima e mínima pertinentes à coluna NM_PRODUTO, da tabela PRODUTOS:
SELECT MAX(nm_produto),
MIN(nm_produto)
FROM produtos;
MAX MIN
Yell criativo 2412: O Retorno
A data máxima ocorre no ponto mais recente no tempo e a data mínima, no ponto mais
antigo. Para exemplificar o uso das funções agregadas MAX(x) e MIN(x) manipulando datas, se-
rão obtidos os valores mínimo e máximo dos valores associados à coluna DT_NASCIMENTO, da
tabela CLIENTES.
SELECT MAX(DT_NASCIMENTO),
MIN(DT_NASCIMENTO)
FROM clientes;
MAX MIN
16/03/1971 00:00 01/01/1965 00:00
A função agregada que permite obter o desvio padrão de um determinado número é iden-
tificada como STDDEV(x). O desvio padrão é uma função estatística, definido como raiz quadra-
da da variância.
Um exemplo prático é o uso da função STDDEV(x) para obter o desvio padrão dos valores
da coluna PRECO da tabela PRODUTOS. Veja:
SELECT STDDEV(preco)
FROM produtos;
STDDEV
11.0896302572459215
A função SUM(x) permite somar todos os valores presentes em x, retornando a soma

total. O exemplo a seguir realiza o somatório dos valores atrelados à coluna PRECO da tabela
PRODUTOS.
SELECT SUM(preco) AS "SOMA TOTAL DA COLUNA"

FROM produtos;
SOMA TOTAL DA COLUNA

236.77
A variância é uma função estatística definida como a dispersão ou a variação de um grupo

de números em uma amostra, ou seja, é equivalente ao quadrado do desvio padrão. A função
agregada SQL utilizada para obter a variância de um número qualquer e/ou de valores associa-
dos a uma determinada coluna é identificada como VARIANCE(x). Similar ao exemplo anterior, a
coluna PRECO será utilizada para extrairmos a variância dos valores vinculados a essa coluna da
tabela PRODUTOS. Acompanhe:
SELECT VARIANCE(preco) AS "VARIÂNCIA DA COLUNA"

FROM produtos;
VARIÂNCIA DA COLUNA
122.979899242424242
Manipulando Data e Hora

O tipo de dado date armazena o século, todos os quatro dígitos de um ano, o mês, o dia, a
hora, o minuto e o segundo. Já o tipo timestamp armazena o século, todos os quatro dígitos de
um ano, o mês, o dia, a hora, o minuto e o segundo, tendo como vantagem o armazenamento
de frações de segundo e fuso horário.
Utilizar datas no padrão ANSI em instruções SQL é conveniente, pois permite que tais ins-
truções possam ser executadas em qualquer SGBD, independente do fabricante.
As funções TO_CHAR(x, string) e DATE são utilizadas para realizar a conversão de uma de-
terminada data/hora em uma string e vice-versa. A função DATE sem parênteses realiza a forma-
tação de uma sequência de caracteres em um determinado formato, esse indicado à sua direita.
No exemplo a seguir, TO_CHAR(x, string) converte a data associada à coluna DT_NASCIMENTO
da tabela CLIENTES em uma string com o formato MONTH DD, YYYY.
SELECT id_cliente,
TO_CHAR(dt_nascimento, 'MONTH DD YYYY')
FROM clientes;
ID_CLIENTE TO_CHAR
1 JANUARY 01 1965
3 MARCH 16 1971
4
5 MAY 20 1970
6 JANUARY 01 1970
2 FEBRUARY 05 1968

O próximo exemplo obtém a data e a hora atual do servidor de BD utilizando a função

NOW(). Na sequência é realizada a conversão dessa data e hora em uma string usando a função
TO_CHAR() com o formato de 24 horas.
SELECT TO_CHAR(now(),
'MONTH DD YYYY, HH24:MI:SS');
TO_CHAR
JANUARY 29 2010, 17:38:16
Agora, converteremos a data 5 de fevereiro de 1967 em uma string com o formato MON-
TH DD, YYYY, utilizando em conjunto a função TO_CHAR() e DATE. Veja a seguir:
SELECT TO_CHAR(DATE('05-02-1967'),
'MONTH DD, YYYY');
TO_CHAR
FEBRUARY 05, 1967
A função DATE também pode ser utilizada em conjunto com os operadores relacionais. Por
exemplo, imagine que desejamos recuperar todos os CLIENTES que possuem data de nascimen-
to (coluna DT_NASCIMENTO) posterior à data de 01 janeiro de 1971. A instrução SQL exemplifi-
ca o uso da função DATE que resolveria nosso problema:
SELECT nm_cliente,
dt_nascimento
FROM clientes
WHERE dt_nascimento > DATE '1971-01-01';
nm_cliente dt_nascimento
Marcelo 16/03/1971 00:00
A função EXTRACT() é responsável por extrair, por exemplo, o dia, o mês, o ano, a hora, o
minuto e o segundo de uma determinada data ou hora. No próximo exemplo, observaremos o
uso da função EXTRACT() para obter o dia, mês e ano da data de nascimento dos registros asso-
ciados à coluna nomeada de DT_NASCIMENTO da tabela CLIENTES. Acompanhe:
SELECT dt_nascimento,
EXTRACT(day FROM DT_NASCIMENTO) AS Dia,
EXTRACT(month FROM DT_NASCIMENTO) AS Mês,
EXTRACT(year FROM DT_NASCIMENTO) AS Ano
FROM clientes;
dt_nascimento dia mês ano

01/01/1965 00:00 1 1 1965
16/03/1971 00:00 16 3 1971
20/05/1970 00:00 20 5 1970
01/01/1970 00:00 1 1 1970
05/02/1968 00:00 5 2 1968
Esse exemplo também explora a função EXTRACT(). Observe as horas, minutos e segundos
do horário atual do sistema, obtido por meio da função NOW():
SELECT now(),
EXTRACT(hour FROM now()) AS Hora,
EXTRACT(minute FROM now()) AS Minuto,
EXTRACT(second FROM now()) AS Segundo;
now hora minuto Segundo

2011-11-12 15:14:15.786-03 15 14 15.786
A função AGE(), por sua vez, retorna a diferença de tempo entre duas datas. Para exempli-
ficar o uso dessa função, utilizaremos duas datas (coluna DT_NASCIMENTO e '2007-09-15') para
que seja retornada a diferença de tempo entre elas. Veja a seguir:
SELECT nm_cliente,
AGE('2011-12-31', dt_nascimento)
FROM clientes;
nm_cliente age
João 46 years 11 mons 30 days
Marcelo 40 years 9 mons 15 days
Henrique
Dolores 41 years 7 mons 11 days
Frederico 41 years 11 mons 30 days
Silvia 43 years 10 mons 26 days
Agrupando Tuplas/Linhas
Imagine que é preciso obter o preço médio dos diferentes tipos de produtos da tabela
PRODUTOS. Para facilitar essa tarefa, a cláusula GROUP BY deverá ser utilizada para agrupar as
tuplas/linhas semelhantes, ou seja, GROUP BY permite agrupar tuplas/linhas em uma tabela e
obter alguma informação sobre esses grupos de tuplas/linhas. Pensemos em um exemplo em
que a cláusula GROUP BY é utilizada para agrupar tuplas/linhas em blocos com um valor comum
de coluna, agrupando as tuplas/linhas da tabela PRODUTOS em blocos com o mesmo valor de
ID_TIPO_PRODUTO. Acompanhe a seguir:
SELECT id_tipo_produto
FROM produtos
GROUP BY id_tipo_produto;
id_tipo_produto
4
1
3
2
Outro exemplo é imaginar várias colunas sendo utilizadas, em que as colunas ID_PRODU-
TO e ID_CLIENTE da tabela COMPRAS são incluídas na cláusula GROUP BY. Veja:

SELECT id_produto,
id_cliente
FROM compras
GROUP BY id_produto, id_cliente;
id_produto id_cliente
4 1
2 2
3 1
1 2
1 1
Mais um exemplo é a cláusula GROUP BY sendo mesclada com a função agregada COUNT(x),
permitindo efetuar o cálculo no grupo de tuplas/linhas em cada bloco, retornando um valor por
bloco. O resultado é o número de tuplas/linhas com o mesmo valor de ID_TIPO_PRODUTO da
tabela PRODUTOS. Observe:
COUNT(id_produto) AS "Total por Tipo de Produto"
FROM produtos
GROUP BY id_tipo_produto
ORDER BY id_tipo_produto;
id_tipo_produto Total por Tipo de Produto

1 2
2 4
3 2
4 3
1
No próximo exemplo, GROUP BY se junta à função agregada AVG(x). Elas são utilizadas
para obter o preço médio dos diferentes tipos de produtos da tabela PRODUTOS.
AVG(preco) AS "Média dos Preços"
FROM produtos
id_tipo_produto Média dos Preços

1 24.9750000000000000
2 26.2200000000000000
3 13.2400000000000000
4 13.9900000000000000
13.4900000000000000
A utilização incorreta das chamadas funções agregadas ocorre quando a consulta contém
uma função agregada e recupera colunas não inseridas dentro da função agregada. Essas colu-
nas devem ser colocadas em uma cláusula GROUP BY. Para ilustrar o uso incorreto das chamadas
funções agregadas, tentaremos recuperar a coluna ID_TIPO_PRODUTO e AVG(preco) e omitir

uma cláusula GROUP BY para o ID_TIPO_PRODUTO, gerando, assim, uma mensagem de erro,
conforme apresentado na Figura 15:
AVG(preco)
FROM produtos;
Figura 15 Utilização inadequada da cláusula GROUP BY.
Portanto, quando uma consulta contém uma função agregada e recupera colunas não
inseridas dentro de uma função agregada, essas colunas devem ser colocadas em uma cláusula
GROUP BY.
Também não é permitido utilizar a função agregada para limitar uma cláusula WHERE,
como podemos identificar na mensagem de erro (Figura 16) gerada a partir da consulta a seguir:
AVG(preco)
FROM produtos
WHERE AVG(preco) > 20
GROUP BY id_tipo_produto;
Figura 16 Erro pertinente o uso impróprio da função agregada na cláusula WHERE.
A cláusula HAVING é usada para filtrar grupos de tuplas/linhas e inserida posteriormente à

cláusula GROUP BY. Uma observação importante é que GROUP BY pode ser usada sem HAVING,
mas HAVING sempre deve ser usada em conjunto à GROUP BY.
Como exemplo, suponha que seja necessário recuperar os tipos de produtos que têm pre-
ços médios maiores que R$ 20,00. Nesse caso:

• GROUP BY é utilizado para agrupar as tuplas/linhas em blocos com o mesmo valor de

ID_TIPO_PRODUTO.
• HAVING é utilizado para limitar os resultados retornados aos grupos que têm preços
médios superiores a R$ 20,00.
AVG(preco)
FROM produtos
HAVING AVG(preco)> 20;
id_tipo_produto Avg
1 24.9750000000000000
2 26.2200000000000000
No próximo exemplo, as cláusulas WHERE e GROUP BY serão mescladas em uma mesma

consulta, simultaneamente. Primeiro, a cláusula WHERE filtra as tuplas/linhas retornadas. Pos-
teriormente, a cláusula GROUP BY agrupa as tuplas/linhas restantes em blocos, ou seja:
• WHERE filtra as tuplas/linhas da tabela PRODUTOS, selecionando apenas os produtos
cujo valor do preço seja inferior a R$ 15,00.
• GROUP BY agrupa as tuplas/linhas restantes pela coluna ID_TIPO_PRODUTO.
AVG(preco)
FROM produtos
WHERE preco < 15
id_tipo_produto AVG
2 14.4500000000000000
3 13.2400000000000000
4 12.9900000000000000
13.4900000000000000
Para finalizar os exemplos aplicados no agrupamento de tuplas/linhas, as cláusulas WHE-

RE, GROUP BY e HAVING serão utilizadas juntas em uma única consulta. Primeiro, a cláusula
WHERE filtra as tuplas/linhas; em seguida, a cláusula GROUP BY agrupa as tuplas/linhas restan-
tes em blocos e, finalmente, a cláusula HAVING filtra os grupos de tuplas/linhas.
• WHERE filtra as tuplas/linhas da tabela PRODUTOS, selecionando os produtos cujo pre-
ço seja menor que R$ 45,00.
• GROUP BY agrupa as tuplas/linhas restantes pela coluna ID_TIPO_PRODUTO.
• HAVING filtra os grupos de tuplas/linhas, selecionando aqueles cujo preço médio seja
superior a R$ 13,00.
AVG(preco)
FROM produtos
WHERE preco < 15
HAVING AVG(preco) > 13
id_tipo_produto AVG
2 14.4500000000000000
3 13.2400000000000000
13.4900000000000000
Subconsultas
Basicamente, existem dois tipos de subconsultas, como detalharemos a seguir:
• Única tupla/linha: retornam zero ou uma tupla/linha para a instrução SQL externa.
Existe um caso especial de subconsulta de uma única tupla/linha que contém exata-
mente uma coluna, a qual é chamada de subconsulta escalar.
• Várias tuplas/linhas: retornam uma ou mais tuplas/linhas para a instrução SQL externa.
Além disso, dentre as subconsultas que podem retornar uma ou várias tuplas/linhas, três
tipos são identificadas como:
• Correlacionadas: referenciam uma ou mais colunas na instrução SQL externa. Elas são
chamadas de subconsultas correlacionadas porque são relacionadas à instrução SQL
externa por meio das mesmas colunas.
• Aninhadas: inseridas dentro de outra subconsulta. É permitido aninhar subconsultas
até uma profundidade de 255.
• Várias colunas: retornam mais de uma coluna para a instrução SQL externa.
Uma subconsulta de uma única tupla/linha pode ser inserida em uma cláusula WHERE,
HAVING ou FROM de uma instrução SELECT. Imagine que é necessário recuperar os registros de
NM_CLIENTE e SOBRENOME da tabela CLIENTES, cujo valor do SOBRENOME corresponda, por
exemplo, a Ribeiro. A seguinte instrução SQL poderia ser utilizada:
SELECT nm_cliente,
sobrenome
FROM clientes
WHERE id_cliente = (SELECT id_cliente
FROM clientes
WHERE sobrenome = 'Ribeiro');
nm_cliente sobrenome
Marcelo Ribeiro
Analisando essa consulta, podemos observar que a subconsulta na cláusula WHERE é:
SELECT id_cliente
FROM clientes
WHERE sobrenome = 'Ribeiro';
id_cliente
3

Essa subconsulta é executada primeiro (e apenas uma única vez), retornando o ID_CLIEN-
TE da coluna cujo valor do SOBRENOME corresponda a Ribeiro. O valor do ID_CLIENTE para essa
tupla/linha é 3, o qual é passado para a cláusula WHERE da consulta externa.
É possível utilizar outros operadores de comparação (<>, <, >, <= e >=) em uma subcon-
sulta de uma única tupla/linha, por exemplo, para obter o preço médio dos produtos, sendo ele
passado para a cláusula WHERE da consulta externa. A consulta interna retorna os valores de
ID_PRODUTO, NM_PRODUTO e PRECO dos produtos cujo preço seja maior do que a média de
preços. Acompanhe:
SELECT id_produto,
nm_produto,
preco
FROM produtos
WHERE preco > (SELECT AVG(preco)
FROM produtos);
id_produto nm_produto preco

1 Ciência Moderna 19.95
2 Química 30.00
3 Supernova 25.99
6 Arquivos Z 49.99
O exemplo a seguir apresenta a decomposição da consulta anterior, executando a subcon-

sulta separadamente:
SELECT AVG(preco)
FROM produtos;
AVG
19.7308333333333
Podemos observar que essa subconsulta é um exemplo de subconsulta escalar, pois re-
torna exatamente uma tupla/linha contendo apenas uma coluna. O valor retornado por uma
subconsulta escalar é tratado como um único valor escalar.
Existe também a possibilidade de inserir uma subconsulta na cláusula HAVING de uma
consulta externa, permitindo filtrar grupos de tuplas/linhas com base no resultado retornado
por sua subconsulta. Como exemplo, recuperaremos o valor do ID_TIPO_PRODUTO e o preço
médio dos produtos cujo preço médio seja inferior ao preço correspondente aos produtos. Veja:
AVG(preco)
FROM produtos
HAVING AVG(preco) < (SELECT MAX(preco)
FROM produtos)
id_tipo_produto AVG
1 24.975000000000000
2 26.220000000000000
id_tipo_produto AVG
3 13.240000000000000
4 13.990000000000000
13.490000000000000
As consultas identificadas como in line são aquelas que permitem inserir uma subconsulta
na cláusula FROM de uma consulta externa. Para ilustrar essa técnica, a próxima instrução SQL
recuperará os registros pertinentes às colunas ID_PRODUTO e NM_PRODUTO da tabela PRODU-
TOS, cujo valor da coluna ID_PRODUTO seja inferior ao número três.

FROM (SELECT *
FROM produtos
WHERE id_produto < 3) AS Interna;
No que diz respeito à cláusula FROM da consulta externa, a saída da subconsulta é apenas
outra fonte de dados.
No próximo exemplo, dotado de maior complexidade, recuperamos os valores correspon-
dentes às colunas ID_PRODUTO e PRECO da tabela PRODUTOS na consulta externa. A subcon-
sulta recupera o número de vezes que um determinado produto foi comprado:
SELECT produtos.id_produto,
preco,
Dados_Compra.Contagem_Produto
FROM produtos, (SELECT id_produto,
COUNT(id_produto) AS Contagem_Produto
FROM compras
GROUP BY id_produto) AS Dados_Compra
WHERE produtos.id_produto = Dados_Compra.id_produto;
id_produto preco contagem_produto

4 13.95 1
1 19.95 2
3 25.99 1
2 30.00 1
Uma consulta de várias tuplas/linhas retorna uma ou mais tuplas/linhas para uma instru-
ção SQL externa. Os operadores IN, ANY e ALL são utilizados para realizar o tratamento de uma
subconsulta que retorna várias tuplas/linhas, permitindo verificar se o valor de uma coluna está
contido em uma lista de valores.
A lista de valores pode vir dos resultados retornados por uma subconsulta. O exemplo a
seguir utiliza o operador IN para verificar se um valor de ID_PRODUTO da tabela PRODUTOS está
na lista de valores retornada pela subconsulta.
SELECT id_produto,
nm_produto
FROM produtos
WHERE id_produto IN (SELECT id_produto
FROM produtos
WHERE nm_produto LIKE '%e%');

id_produto nm_produto
1 Ciência Moderna
3 Supernova
4 Tanque de Guerra
7 2412: O Retorno
9 De outro planeta
12 Yell criativo
13 My Front Line
No próximo exemplo, é utilizado o operador NOT IN para executar a lógica oposta de IN,
ou seja, obter os produtos que não estão na tabela COMPRAS.
SELECT id_produto,
nm_produto
FROM produtos
WHERE id_produto NOT IN (SELECT id_produto
FROM compras);
6 Arquivos Z
7 2412: O Retorno
8 Força G
9 De outro planeta
10 Música clássica
11 Pop 3
12 Yell criativo
13 My Front Line
O operador ANY é utilizado para comparar um valor com qualquer valor presente em uma
lista. Podemos, ainda, inserir um operador (=, <>, >, <, <= ou >=) antes de ANY. Para exemplificar
sua aplicabilidade, recuperaremos os funcionários cujo salário seja menor do que qualquer um
dos salários mais baixos da tabela GRADES_SALARIOS. Observe:
SELECT id_funcionario,
nm_funcionario,
salario
FROM funcionarios
WHERE salario < ANY (SELECT salario_minimo
FROM grades_salarios);
id_funcionario nm_funcionario salario

2 Rubens 600000
3 Frederico 150000
4 Susana 500000
Por sua vez, o operador ALL é utilizado para comparar um valor com todos os valores pre-
sentes em uma lista. Semelhante ao operador ANY, ALL também permite inserir um operador (=,
<>, >, <, <= ou >=) antes dele. Modificamos o exemplo anterior para obter os funcionários cujo
salário seja superior a todos os salários mais altos da tabela GRADES_SALARIOS. Veja a seguir:
nm_funcionario,
salario
FROM funcionarios
WHERE salario > ALL (SELECT salario_maximo
Como podemos identificar, não existe nenhum funcionário que tenha o salário maior do
que o salário mais alto da tabela GRADES_SALARIOS.
Quanto às subconsultas que manipulam várias tuplas/linhas, existe ainda a possibilida-
de de escrevermos subconsultas que retornam várias colunas. Por exemplo, suponha que seja
necessário recuperarmos os produtos com o menor preço para cada grupo de tipo de produto.
Nesse caso, são retornados o valor correspondente ao ID_TIPO_PRODUTO e o valor do PRECO
mínimo para cada grupo de produtos, onde os mesmos são comparados com os valores ID_
TIPO_PRODUTO e PRECO para cada produto na cláusula WHERE da consulta externa.
SELECT id_produto,
id_tipo_produto,
nm_produto,
preco
FROM produtos
WHERE (id_tipo_produto, preco) IN (SELECT id_tipo_produto,
MIN(preco)
FROM produtos
GROUP BY id_tipo_produto);
id_produto id_tipo_produto nm_produto preco

1 1 Ciência Moderna 19.95
4 2 Tanque de Guerra 13.95
9 3 De outro planeta 12.99
10 4 Música clássica 10.99
Uma subconsulta considerada correlacionada referencia uma ou mais colunas na instru-

ção SQL. São nomeadas de correlacionadas, pois são vinculadas à instrução SQL externa por
meio das mesmas colunas. A subconsulta correlacionada é executada uma vez para cada tu-
pla/linha na consulta externa, diferenciando-se da subconsulta não correlacionada, a qual é
executada apenas uma única vez antes da execução da consulta externa. Esse tipo de consulta
também nos permite trabalhar com valores nulos. Por exemplo, para o uso de uma subconsulta
correlacionada, recuperaremos todos os produtos que possuem preço maior do que a média
para o tipo de produto. Veja a seguir:
SELECT id_produto,
id_tipo_produto,
nm_produto,
preco
FROM produtos externa
WHERE preco > (SELECT AVG(preco)
FROM produtos interna
WHERE interna.id_tipo_produto = externa.id_tipo_produto);

id_produto id_tipo_produto nm_produto preco

2 1 Química 30.00
6 2 Arquivos Z 49.99
8 3 Força G 13.49
11 4 Pop 3 15.99
12 4 Yell criativo 14.99
Utilizamos o apelido externa para rotular a consulta externa e o apelido interna para a
subconsulta interna. A referência à coluna ID_TIPO_PRODUTO nas partes interna e externa é o
que torna a subconsulta interna correlacionada à consulta externa. Em uma subconsulta corre-
lacionada, cada tupla/linha da consulta externa é passada por vez para a subconsulta.
A subconsulta lê uma tupla/linha de cada vez da consulta externa e a aplica na subconsulta
até que todas as tuplas/linhas da consulta externa sejam processadas. Em nosso exemplo, a con-
sulta externa recupera cada tupla/linha da tabela PRODUTOS e passa para a consulta interna.
Cada tupla/linha é lida pela consulta interna, a qual calcula o preço médio de cada produto onde
o valor de ID_TIPO_PRODUTO na consulta interna corresponda ao valor de ID_TIPO_PRODUTO
na consulta externa.
Os operadores EXISTS e NOT EXISTS podem ser utilizados em uma subconsulta correlacio-
nada. O operador EXISTS verifica a existência de tuplas/linhas retornadas por uma subconsulta.
Embora você possa usar EXISTS em subconsultas não correlacionadas, em geral ele é utilizado
em subconsultas correlacionadas. O operador NOT EXISTS executa a lógica oposta de EXISTS.
Como exemplo do uso do operador EXISTS em uma subconsulta, recuperaremos os funcionários
que gerenciam outros funcionários. Acompanhe:
nm_funcionario
FROM funcionarios externa
WHERE EXISTS (SELECT id_funcionario
FROM funcionarios interna
WHERE interna.id_gerente = externa.id_funcionario);
id_funcionario nm_funcionario
1 Jaime
2 Rubens
Como EXISTS apenas verifica a existência de tuplas/linhas retornadas pela subconsulta,

uma subconsulta não precisa retornar uma coluna (ela pode retornar um valor literal), e essa
característica pode melhorar o desempenho da consulta. Agora, reescreveremos o exemplo an-
terior com a subconsulta retornando o valor literal 1.
nm_funcionario
FROM funcionarios externa
WHERE EXISTS (SELECT 1
FROM funcionarios interna
WHERE interna.id_gerente = externa.id_funcionario);
id_funcionario nm_funcionario
1 Jaime
2 Rubens
Independente de a subconsulta retornar uma ou mais tuplas/linhas, o operador EXISTS

retornará verdadeiro. Caso a subconsulta não retorne uma tupla/linha, EXISTS retornará falso.
Para demonstrar o uso do NOT EXISTS, a próxima instrução SQL recuperará os produtos
que não foram comprados. Veja:
SELECT id_produto,
nm_produto
FROM produtos externa
WHERE NOT EXISTS (SELECT 1
FROM compras interna
WHERE interna.id_produto = externa.id_produto);
6 Arquivos Z
7 2412: O Retorno
8 Força G
9 De outro planeta
10 Música clássica
11 Pop 3
12 Yell criativo
13 My Front Line
Portanto, o operador EXISTS verifica a existência de tuplas/linhas, enquanto IN verifica os

valores reais. É importante comentar que EXISTS oferece um desempenho melhor em subcon-
sultas, se comparado com o operador IN.
É possível, ainda, aninharmos subconsultas dentro de outras subconsultas até uma pro-
fundidade de 255 subconsultas. Essa técnica deve ser utilizada com moderação, pois o uso de
junções de tabelas reduz o desempenho da consulta. Para exemplificar o uso de subconsultas
aninhadas, observe a próxima instrução SQL, que contém três consultas (uma subconsulta ani-
nhada, uma subconsulta e a consulta externa).
AVG(preco)
FROM produtos
HAVING AVG(preco) < (SELECT MAX(preco)
FROM produtos
WHERE id_tipo_produto IN (SELECT id_produto
FROM compras
WHERE quantidade > 1)
GROUP BY id_tipo_produto)

id_tipo_produto AVG
1 24.9750000000000000
2 26.2200000000000000
3 13.2400000000000000
4 13.9900000000000000
13.4900000000000000
Para finalizar o uso de subconsultas, é possível, em uma instrução UPDATE, definir uma
coluna com o resultado retornado por uma subconsulta de uma única tupla/linha. Por exem-
plo, definir o salário do funcionário cujo número (ID_FUNCIONARIO) corresponda ao Número 4
como a média dos níveis salariais altos retornados por uma subconsulta:
UPDATE funcionarios
SET salario = (SELECT AVG(salario_maximo)
FROM grades_salarios)
WHERE id_funcionario = 4;
O exemplo a seguir utiliza as tuplas/linhas retornadas por uma subconsulta na cláusula

WHERE de uma instrução DELETE, removendo o funcionário cujo valor salarial seja maior do que
a média dos níveis salariais altos. Veja a seguir:
DELETE
FROM funcionarios
WHERE salario > (SELECT AVG(salario_maximo)
9. ESTRUTURA DA LINGUAGEM SQL – DDL

Neste tópico, estudaremos como modificar a estrutura das tabelas.
Modificando a Estrutura das Tabelas

Quando criamos uma tabela qualquer e na sequência, constatamos que cometemos al-
gum tipo de equívoco, ou se, eventualmente, torna-se imprescindível modificar a estrutura da
mesma, você, normalmente, poderá remover a tabela e criá-la novamente.
Entretanto, esta não é uma alternativa muito conveniente, sobretudo se a tabela já con-
tiver dados, ou se a tabela é referenciada por outros objetos de banco de dados (por exemplo,
uma restrição de chave estrangeira). Nesses casos, o PostgreSQL fornece uma gama de coman-
dos para realizar as modificações em tabelas existentes. Percebe-se de que este conceito é to-
talmente distinto se compararmos com as alterações de dados contidos na tabela: nesse tópico
estamos interessados exclusivamente em alterar a definição, ou estrutura, de uma determinada
tabela.
Por meio dos comandos pertinentes a DDL, podemos:
• adicionar e remover colunas;
• adicionar e remover restrições;
• alterar valores configurados como padrão (default);
• alterar tipos de dados (domínio) de uma determinada coluna;
• renomear colunas;
• renomear tabelas.
Basicamente, todas essas ações são implementadas utilizando o comando ALTER TABLE.
Adicionando uma Coluna

Para adicionarmos uma determinada coluna em uma tabela qualquer, utilizamos o coman-
do exemplificado a seguir:
ALTER TABLE tb_produtos

ADD COLUMN descricao_produto TEXT;
A nova coluna intitulada de descricao_produto será adicionada na tb_produtos, com valores

nulos (NULL), caso você não especifique uma cláusula DEFAULT.
Eventualmente, você poderá, simultaneamente, adicionar uma restrição (CONSTRAINT)
de verificação (CHECK) para a coluna, conforme sintaxe apresentada a seguir:

ADD COLUMN descricao_produto TEXT CHECK (descricao_produto <> '');
No caso anterior, uma nova coluna é adicionada na tb_produtos, paralelamente a inclusão

de uma restrição de verificação, ou seja, a restrição CHECK garantirá que os valores associados a
essa nova coluna, não poderão ser valores nulos.
É importante mencionar que, essa restrição de checagem poderia ser adicionar no mo-
mento da criação da tabela (CREATE TABLE). Apenas tenha em mente de que o valor padrão
(DEFAULT), obrigatoriamente, deverá satisfazer as restrições indicadas ou a inclusão da coluna
irá acarretar em falha. Normalmente, você poderá adicionar as restrições posteriormente ao
definir uma nova coluna.
Removendo uma Coluna

Para remover uma coluna específica, por exemplo, remover a coluna nomeada de descri-
cao_produto, adicionada anteriormente na tb_produtos, utilize o comando a seguir:

DROP COLUMN descricao_produto;
Repare que, os dados presentes na coluna, ora removida, desaparecem, juntamente com
as eventuais restrições presentes na tabela e vinculadas à coluna descricao_produto.
É permitida a remoção em cascata, ou seja, remover eventuais dependências vinculadas a
coluna, adicionando CASCADE, conforme apresentado a seguir:

DROP COLUMN descricao_produto CASCADE;
Adicionando uma Restrição (Constraint)

Para incluir uma restrição qualquer em uma tabela, utilizamos as sintaxes a seguir. Por
exemplo, imagine a necessidade de adicionar uma restrição de checagem na coluna chamada
de nm_produto para certificar-se de que não será aceito nomes de produtos em branco, e ou
nulos, para essa coluna.

ALTER TABLE tb_produtos ADD CHECK (nm_produto <> '');
Como outro exemplo, podemos considerar a necessidade de adicionar uma restrição de

unicidade à coluna intitulada de nro_produto, conforme comando a seguir:

ADD CONSTRAINT nome_restricao
UNIQUE (nr_produto);
Note que associamos um nome para essa restrição (nome_restricao), promovendo faci-
lidades no que tange eventuais futuras manutenções aplicadas a essa restrição em particular.
Quando não identificamos as restrições impostas às tabelas, o SGBD se encarrega de nomeá-las,
entretanto, fazendo uso de nomenclaturas não tão amigáveis, mesclando números e letras.
Em nosso próximo exemplo, adicionaremos uma restrição de chave-estrangeira, associada
a coluna id_grupo_produto, conforme apresentado a seguir:

ADD FOREIGN KEY (id_grupo_produto)
REFERENCES tb_grupos_produtos;
Para adicionar uma restrição não-nulo, que também pode ser produzida como uma restri-
ção de tabela, faça uso da seguinte sintaxe:

ALTER COLUMN nr_produto SET NOT NULL;
A restrição não-nulo anterior, será verificada imediatamente, sendo assim, os dados pre-
sentes na tabela e, especificamente vinculados a essa coluna, devem satisfazer a restrição antes
que ela possa ser adicionada.
Removendo uma Restrição

Para remover uma restrição, é necessário conhecer previamente o seu nome. Se você
forneceu-lhe um nome, no momento da sua criação, essa tarefa torna-se mais fácil. Caso contrá-
rio, o SGBD será responsável por gerar um nome, normalmente, não familiar, e, você precisará
descobrir antes de realizar qualquer tipo de manutenção/operação. Eventualmente, o comando
psql \d nome_tabela poderá ser útil na obtenção dessa informação, inspecionando os detalhes
das estruturas das tabelas. A seguir, um exemplo de como remover uma restrição, ora nomeada
pelo administrador de banco de dados (DBA):

DROP CONSTRAINT nome_restricao;
Outro exemplo, imagine a necessidade de remover uma restrição não-nulo da coluna inti-
tulada de nr_produto, essa nomeada de nn_tb_produtos_nm_produto.

DROP CONSTRAINT nn_tb_produtos_nm_produto;
Alterando um Valor Padrão de uma Coluna

Para configurar um novo valor padrão atrelado a uma coluna qualquer, o comando a se-
guir poderá ser utilizado. Nesse exemplo, imagine a necessidade de configurar um valor padrão
para a coluna nomeada de preco.

ALTER COLUMN preco SET DEFAULT 1.99;
Repare que o comando anterior não afetará todas as tuplas existentes na tabela, apenas
irá alterar o valor padrão para futuras instruções INSERT.
Para remover qualquer valor padrão, você poderá utilizar o comando a seguir:

ALTER COLUMN preco DROP DEFAULT;
O exemplo anterior é basicamente o mesmo que configura o valor padrão para nulo
(NULL). Entretanto, não é considerado um erro remover um valor padrão que não tenha sido
definido, sobretudo, pelo valor padrão ser implicitamente o valor nulo.
Alterando o Tipo de Dado de uma Coluna

O comando a seguir poderá ser utilizado para converter uma coluna para um tipo de dado
distinto. Imagine à necessidade de converter para NUMERIC, precisão (10,2) a coluna, ora iden-
tificada de preco:

ALTER COLUMN preco TYPE NUMERIC(10,2);
A instrução anterior, apenas obterá êxito se cada dado existente na coluna preco for pas-
sível de conversão para o novo tipo, por meio de uma conversão implícita. Caso seja necessária
uma conversão mais complexa, você poderá adicionar uma cláusula USING responsável por es-
pecificar como converter os novos valores a partir dos dados antigos.
O PostgreSQL tentará converter o valor padrão da coluna (se houver) para o novo tipo
de dado, bem como todas as restrições que envolvem a coluna. Entretanto, essas conversões
poderão falhar, ou produzirem resultados inesperados. Na maioria das vezes, é melhor eliminar
todas as restrições associadas à coluna antes de alterar o seu tipo, e, na sequência, adicionar
novamente as restrições.
Renomeando uma Coluna

Para renomear uma coluna específica, podemos utilizar a sintaxe a seguir. Para esse exem-
plo específico, imagine a necessidade de renomear a coluna nr_produto para numero_produto.

RENAME COLUMN nr_produto TO numero_produto;
Caso, eventualmente, você tenha utilizado o nome da coluna como parte do nome de
uma restrição qualquer, será imprescindível alterar tais identificadores, a fim de evitar futuros
dissabores.

Renomeando uma Tabela

Para esse exemplo, em particular, considere a necessidade de renomear a tabela intitula-
da de tb_produtos para tb_itens. A sintaxe a seguir poderá ser utilizada para contemplar esse
propósito.

RENAME TO tb_itens;
10. INTRODUÇÃO ÀS VISÕES

De acordo com Bianchi (2012):
Uma view é uma maneira alternativa de observação de dados de uma ou mais entidades (tabelas),
que compõem uma base de dados. Pode ser considerada como uma tabela virtual ou uma consulta
armazenada.
Geralmente é recomendável, uma view, implementada encapsulando uma instrução SELECT (busca de
dados para exposição), guarda os dados em uma tabela virtual, armazenando também em cache, pois
todas as consultas ao banco, encapsuladas ou não, ao serem executadas, são armazenadas em cache.
Por este motivo, pode ser mais rápido ter uma consulta armazenada em forma de view, em vez de ter
que retrabalhar uma instrução.
As views nos possibilitam mais que simplesmente visualizar dados. Elas podem ser implementadas tam-
bém com algumas aplicações de restrição.
Restrição usuário x dados;
Ex.: Seu departamento de vendas não precisa saber ou ter acesso a uma coluna que contém valores
(dados) referentes aos salários dos desenvolvedores.
Restrição usuário x domínio;
Podemos restringir o acesso de um usuário específico a colunas (domínios) específicas (os) de uma
tabela.
Associar vários domínios formando uma única entidade;
Podemos ter várias "JOINs" encapsuladas em uma view, formando somente uma tabela arbitrariamente.
Agregar informações, em vez de fornecer detalhes;
Podemos apresentar um somatório de despesas em ligações de um determinado usuário, restringindo
o acesso aos detalhes da conta.
As vantagens de usar views são:
Economizar tempo com retrabalho;
Você não precisa escrever aquela instrução enorme. Escreva uma vez e armazene!
Velocidade de acesso às informações;
Uma vez compilada, o seu recordset (conjunto de dados) é armazenado em uma tabela temporária
(virtual).
Mascarar a complexidade do banco de dados;
As views isolam do usuário a complexidade do banco de dados. Nomes de domínios podem ser referen-
ciados com literais e outros recursos. Isso proporciona aos desenvolvedores a capacidade de alterar a
estrutura sem afetar a interação do usuário com o banco de dados.
Simplifica o gerenciamento de permissão de usuários;
Em vez de conceder permissões para que os usuários contem tabelas base, os proprietários de banco de
dados podem conceder permissões para que os usuários consultem dados somente através de views.
Isso também protege as alterações na estrutura das tabelas-base subjacentes. Os usuários não serão
interrompidos durante uma visualização de dados.
Organizar dados a serem exportados para outros aplicativos;
Você pode criar uma view baseada em uma consulta complexa, que associe até 32 tabelas e depois
exportar dados para outro aplicativo para análise adicional. Pode ser gerado um arquivo de DUMP*
automaticamente.
Criando views
Quando você cria uma VIEW, o SQL Server verifica a existência de objetos que contém referências em
uma definição de view. O nome de sua view deve seguir o padrão de regra de identificadores. A espe-
cificação do nome do proprietário de uma view é opcional* (caso você queira tornar uma view pública,
declare "dbo.nome_entidade"). Não atribua a uma view, um nome já utilizado para outro objeto exis-
tente no mesmo banco de dados.
Até o momento, você não sabe como criar uma view, onde criá-la, nem os passos para
sua criação – ou seja, você tem apenas a teoria. Mas, daqui em diante, serão apresentados os
comandos para a criação das views.
Então, vamos lá?!
Você cria uma view (visão) usando CREATE VIEW, que tem a sintaxe detalhada a seguir.
Observe:
CREATE [ OR REPLACE ][ TEMP | TEMPORARY ]VIEW nome_view [ (NOME DA

COLUNA [,...] )]
AS
SELECT comando_select;
Onde:
1) OR REPLACE significa que a visão substitui outra já existente.
2) TEMP | TEMPORARY define se a view será temporária, ou seja, se existirá somente
naquela sessão SQL.
3) nome_view é simplesmente o identificador da visão, ou seja, o nome da visão a qual
você referenciará quando julgar necessário.
4) nome da(s) coluna(s) é uma lista opcional do(s) nome(s) da(s) coluna(s) pertinente(s)
à view. Caso a lista de nomes não seja fornecida, é (são) utilizado(s) o(s) nome(s) da(s)
coluna(s) da própria consulta.
5) comando_select é a consulta propriamente dita, ou seja, uma instrução SELECT que
permitirá realizar a captura da(s) coluna(s) e tupla(s)/linha(s) da view.
É importante também mencionar a existência de dois tipos de views:
1) As consideradas views simples, que contêm uma consulta (query) que recupera regis-
tros de uma única tabela-base.
2) Views complexas, que contêm uma consulta que:
a) Recupera registros de várias tabelas-base.
b) Agrupa tuplas/linhas usando uma cláusula GROUP BY ou DISTINCT.
c) Contém uma chamada a uma determinada função.
O exemplo a seguir cria uma visão (view) nomeada de visao_produtos_baratos, cuja con-
sulta recupera produtos da tabela PRODUTOS, em que o preço do produto seja inferior a R$
15,00. Acompanhe:
CREATE VIEW visao_produtos_baratos AS

SELECT *
FROM produtos
WHERE preco < 15;
No próximo exemplo, será criada uma visão (view) identificada como visao_funcionarios,
cuja consulta recuperará todas as colunas, exceto as colunas SALARIO e FG_ATIVO da tabela
FUNCIONARIOS.

CREATE VIEW visao_funcionarios AS

id_gerente,
nm_funcionario,
sobrenome_funcionario,
cargo
FROM funcionarios;
Você perceberá que, após a criação de uma determinada visão (view), podemos usá-la
para acessar a tabela-base a qualquer momento e quantas vezes julgarmos necessário. A próxi-
ma consulta exemplifica a recuperação das tuplas/linhas da view visao_produtos_baratos. Veja:
SELECT id_produto,
nm_produto,
preco
FROM visao_produtos_baratos;
id_produto nm_produto preco

4 Tanque de Guerra 13.95
7 2412: O Retorno 14.95
8 Força G 13.49
9 De outro planeta 12.99
10 Música clássica 10.99
12 Yell criativo 14.99
13 My Front Line 13.49
No próximo exemplo de manipulação de view, você poderá recuperar todas as tuplas/

linhas oriundas da view visao_funcionarios.
SELECT *
FROM visao_funcionarios;
id_funcionario id_gerente nm_funcionario sobrenome_funcionario Cargo

1 Jaime Tenório Diretor Executivo
2 1 Rubens Cardoso Gerente de Vendas
3 2 Frederico Munhoz Vendedor
4 2 Susana Coimbra Vendedor
Veja, no exemplo a seguir, a criação de uma view nomeada de visao_tipos_produtos, cuja

consulta realiza uma junção externa completa (full outer join) nas tabelas PRODUTOS e TIPOS_
PRODUTOS, usando a sintaxe SQL/92.
CREATE VIEW visao_tipos_produtos AS

SELECT p.id_produto,
p.nm_produto,
tp.ds_tipo_produto,
p.preco
FROM produtos p
FULL OUTER JOIN tipos_produtos tp
USING (id_tipo_produto)
ORDER BY p.id_produto;
A seguir, exemplificaremos como executar uma consulta a partir de uma view (nesse caso,
a view criada anteriormente e identificada de visao_tipos_produtos).
SELECT *
FROM visao_tipos_produtos;
id_produto nm_produto ds_tipo_produto preco

1 Ciência Moderna Livro 19.95
2 Química Livro 30.00
3 Supernova Vídeo 25.99
4 Tanque de Guerra Vídeo 13.95
6 Arquivos Z Vídeo 49.99
7 2412: O Retorno Vídeo 14.95
8 Força G DVD 13.49
9 De outro planeta DVD 12.99
10 Música clássica CD 10.99
11 Pop 3 CD 15.99
12 Yell criativo CD 14.99
13 My Front Line 13.49
Revista
O exemplo a seguir realiza a criação de views complexas, criando uma view chamada vi-
sao_media_produto, cuja consulta utiliza:
• Uma cláusula WHERE responsável por filtrar as tuplas/linhas da tabela PRODUTOS, sen-
do o valor do preço inferior a R$ 15,00.
• Uma cláusula GROUP BY para agrupar as tuplas/linhas pela coluna ID_TIPO_PRODUTO.
• E por fim, uma cláusula HAVING para filtrar os grupos de tuplas/linhas em que o preço
médio seja superior a R$ 13,00.
CREATE VIEW visao_media_produto AS

AVG(preco) AS Média_Preço
FROM produtos
WHERE preco < 15.00
HAVING AVG(preco) > 13.00
A seguir, realizaremos uma consulta utilizando a view criada anteriormente, identificada

por visao_media_produto.
SELECT *
FROM visao_media_produto;
id_tipo_produto média_preço
2 14.4500000000000000
3 13.2400000000000000
13.4900000000000000

É possível substituir uma view completamente usando o comando CREATE OR REPLACE

VIEW. Em nosso exemplo, a utilização do CREATE OR REPLACE VIEW se faz necessária para subs-
tituir a view visao_media_produto:
CREATE OR REPLACE VIEW visao_media_produto AS

AVG(preco) AS Média_Preço
FROM produtos
WHERE preco < 12.00
HAVING AVG(preco) > 11.00
Para encerrar nossa discussão sobre visões (views), você também poderá excluir uma view
por meio do comando DROP VIEW. O exemplo seguinte exclui a visão identificada como visao_
media_produtos:
DROP VIEW visao_media_produto;

unidade:
1) Você aprendeu que a linguagem SQL utilizada no PostgreSQL é segmentada em quatro subconjuntos. Quais são
esses quatro subconjuntos que constituem a base das instruções SQL?
2) Para qual tarefa será mais apropriado usar o comando DISTINCT?

a) Identificar linhas duplicadas na tabela.
b) Identificar quais colunas possuem dados únicos.
c) Eliminar colunas duplicadas na tabela.
d) Eliminar linhas duplicadas no resultado.
3) Considerando a consulta a seguir, quais nomes são mostrados?

SELECT name
FROM employee
WHERE name LIKE '_a%';
a) Nomes que começam com a letra a.

b) Nomes que começam com a letra a ou A.
c) Nomes contendo a letra a como segunda letra.
d) Nomes contendo a como uma letra, exceto a primeira.
4) Para qual tarefa você precisará usar o operador BETWEEN?
a) Consulta de tabelas com valores desconhecidos.
b) Consulta de tabelas para uma faixa de valores.
c) Consulta de tabelas para um tipo de caractere.
d) Consulta de tabelas para valores específicos de uma lista.
5) Em um comando SELECT, qual cláusula poderá ser usada para excluir linhas, antes de agrupá-las?
a) INTO.
b) WHERE.
c) HAVING.
d) ORDER BY.
6) Qual cláusula SELECT será avaliada primeiro na consulta a seguir?

SELECT name, salary, dept_id
FROM employee
WHERE salary >
(SELECT AVG(salary)
FROM employee
WHERE dept_no =
(SELECT dept_no
FROM employee
WHERE last_name =
(SELECT last_name
FROM employee
WHERE salary > 50000)));
a) SELECT last_name.
b) SELECT dept_no.
c) SELECT AVG(salary).
d) SELECT name, salary, dept_id.
7) Ao tentar criar a tabela ALPHA_3000 com o comando a seguir, qual linha de comando causará erro?
1. CREATE TABLE alpha_3000
2. (3000_id NUMBER(9)
3. CONSTRAINT alpha_3000_id_pk PRIMARY KEY,
4. name VARCHAR2(25),
5. title VARCHAR2(25),
6. idname VARCHAR2(25)
7. CONSTRAINT alpha_3000_idname_nn NOT NULL);
a) Linha 1.
b) Linha 3.
c) Linha 2.
d) Linha 7.
8) O que acontece quando você realiza o UPDATE em uma tabela com a cláusula WHERE?
a) O comando não será executado.
b) Somente as linhas específicas serão updated.
c) Todas as linhas na tabela serão updated.
d) O comando será executado, mas as atualizações não serão feitas.
9) Quais tarefas são executadas com o comando DDL a seguir?
ALTER TABLE employee
ADD (end_date DATE);
a) Uma constraint é criada em uma coluna existente.

b) Uma constraint é modificada em uma coluna existente.
c) Uma nova coluna com uma constraint é criada em uma tabela.
d) Uma nova coluna sem constraint é criada em uma tabela.
10) Os comandos SQL podem dividir-se em: DML (Data Manipulation Language), DDL (Data Definition Language)
e DCL (Data Control Language). DCL controla os aspectos de autorização de dados e licenças de usuários para
controlar quem tem acesso para ver ou manipular dados dentro do banco de dados.
São comandos DCL:
a) GRANT e REVOKE.
b) DELETE e REVOKE.
c) DROP VIEW e GRANT.
d) SELECT e DROP VIEW.
e) ALTER PASSWORD e CREATE INDEX.

Gabarito
2) e.
3) c.
4) b.
5) b.
6) a.
7) c.
8) b.
9) d.
10) a.
12. CONSIDERAÇÕES
A linguagem SQL, conteúdo estudado nesta unidade, é bastante utilizada no mundo todo
para acessar e manipular os dados armazenados em bancos de dados.
Os conceitos foram demonstrados e apresentados por meio de exemplos de um esquema
(database) criado inicialmente, identificado por FACULDADE, com o intuito de facilitar sua assi-
milação e demonstrar, assim como escrever, os comandos da linguagem SQL.
Na próxima unidade, você terá a oportunidade de aprender os conceitos de Dependência
Funcional para um banco de dados.
13. E-REFERÊNCIA
BIANCHI, W. Introdução a views. Disponível em: <http://www.devmedia.com.br/introducao-a-views/1614>. Acesso em: 23 out.
2012.

RANGEL, A. L. Projeto, modelagem e desenvolvimento de bancos de dados. Rio de Janeiro: Alta Books, 2004.
ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementação e Administração. 8. ed. São Paulo: Cengage Learning,
2011.
Normalização e Desempenho
em Sistema de Banco de
Dados Relacional
5
1. OBJETIVOS
• Conhecer a dependência dos dados existentes no contexto de Banco de Dados Relacio-
nais.
• Entender o processo de normalização de dados.
• Diferenciar as formas normais e seu emprego.
• Estar apto à realização do processo de normalização de dados.
2. CONTEÚDOS
• Dependência Funcional de um Banco de Dados Relacional.
• Normalização.
• Fatores a serem considerados no Projeto Físico de Banco de Dados Relacional.

guir:
1) Realizar as atividades propostas é uma forma de defrontar os conteúdos aprendidos
com as suas experiências. Por isso, organize-se para realizar todas as atividades suge-
ridas e fique atento aos prazos de entrega.
2) Adquira o hábito da leitura e da pesquisa. Leia livros, revistas e periódicos e consulte

sites; caso encontre alguma novidade relacionada ao conteúdo estudado, compartilhe
com seus colegas de curso.
3) Aceite o desafio de construir uma comunidade interativa, pois, além de significativos
ganhos para sua vida pessoal e profissional, essa interação o colocará em consonância
com as novas exigências do mundo científico e profissional. Afinal, conhecer é exercer
seu direito de cidadania.
4) Esta unidade apresenta aspectos importantes à elaboração de projetos de bancos
de dados bem estruturados, como a normalização. Você notará como é importante
compreender o que é um banco de dados relacional e identificar suas dependências
funcionais. A normalização possui o objetivo de "filtrar" as entidades e os relaciona-
mentos, eliminando elementos indesejáveis sem causar perda de informação nas en-
tidades e nas relações. Ou seja, ela está intimamente relacionada ao desempenho do
banco de dados. No decorrer dos estudos, atente-se ao que deve ser evitado quando
aplicamos a normalização.
5) Faça uso de outros modelos não normalizados para aplicar os principais conceitos de
normalização estudados nessa unidade. Identifique adequadamente as dependências
funcionais parciais, transitivas, multivaloradas e cíclicas.
Na unidade anterior, você teve a oportunidade de aprender como utilizar a linguagem SQL
na criação e manipulação dos bancos de dados por meio dos Sistemas Gerenciadores de Banco
de Dados (SGBD).
Nesta unidade, você estudará um tipo de restrição de integridade conhecido como de-
pendência funcional. Além disso, poderá realizar a normalização de atributos em relações e
conhecer alguns aspectos importantes como o desempenho e a carga de trabalho de um SGBD
ao converter o esquema lógico relacional em um esquema físico.
5. DEPENDÊNCIA FUNCIONAL DE UM BANCO DE DADOS RELACIONAL

A dependência funcional é uma forma de descrever a interdependência de atributos ou
campos nas tabelas de banco de dados. É um tipo de restrição de integridade entre dois conjun-
tos de atributos de dados, sendo declarada pelo administrador do banco de dados e controlada
pelo SGBD.
Para elucidar melhor o estudo da dependência funcional, imagine que o atributo B é de-
pendente funcional do atributo A se cada valor de A determina um e apenas um valor de B. Já a
definição genérica diz que o atributo A determina o atributo B (isso significa que, B é funcional-
mente dependente de A) se todas as linhas da tabela que correspondem em valor ao atributo
A também correspondem em valor ao atributo B. Por exemplo, NUMERO_PROJETO à DESCRI-
ÇÃO_PROJETO, nesse caso, NUMERO_PROJETO é considerado como atributo determinante e a
DESCRICAO_PROJETO, por sua vez, torna-se o atributo dependente.
Torna-se imprescindível a abstração adequada do conceito de dependência funcional, pois
esse conceito é empregado para determinar o conjunto de dependências funcionais de deter-
minada relação e assim, implementar o processo de normalização, o qual trabalha relação por
relação, identificando possíveis dependências e aplicando a normalização adequada.
© U5 – Normalização e Desempenho em Sistema de Banco de Dados Relacional 197
Por exemplo, considere os atributos A e B de uma entidade: pode-se dizer que B é funcio-
nalmente dependente de A se, e somente se, a cada valor de A estiver associado um único valor
de B. Em outras palavras, o CPF de um indivíduo, por exemplo, pode determinar o seu nome;
logo, o nome do indivíduo é dependente do seu CPF.
Considere o conjunto de atributos DataNascimento e Idade da entidade ALUNO. Pode-se
dizer que: o atributo Idade depende funcionalmente do atributo DataNascimento; o atributo
DataNascimento determina a Idade; ou Idade depende de DataNascimento.
Ou ainda, uma vez que você tem um número de CPF (o qual o identifica pelo Nome), é
possível afirmar que o Nome depende funcionalmente do CPF.
Uma dependência funcional é representada pelo símbolo .
Veja como se lê a seguinte notação:
AB
• A determina B.
• B é funcionalmente dependente de A.
Logo, você pode descrever as frases anteriores como:
DataNascimento  Idade
CPF  Nome
O conjunto de dependências funcionais pode ser utilizado para projetar um banco de da-
dos relacional, permitindo uma melhor compreensão dos dados. Entretanto, o estabelecimento
do conjunto de dependências funcionais é tarefa do projetista do banco de dados e deve ser
realizado com cuidado para não gerar restrições com regras difíceis de obedecer e, também, não
ignorar restrições que devem ser cumpridas pelo conjunto.
Existem algumas regras para se encontrar as dependências funcionais. Veja, a seguir, al-
gumas delas:
Separação ou Projetiva
CPF  nome, sexo, então, CPF  nome e CPF  sexo
Leia o exemplo anterior da seguinte maneira:
Se com um número de CPF, eu encontro o nome e o sexo de uma pessoa, então com esse
mesmo número de CPF eu posso encontrar apenas o nome e com este mesmo número eu posso
encontrar apenas o sexo.
Notação: A  BC, então A  B e A  C
União ou Aditiva
CEP  endereço, CEP  Bairro então CEP  endereço, Bairro
Se com um número de CEP, eu encontro o endereço de uma pessoa e com este mesmo
CEP eu encontro o bairro, então com CEP é possível determinar o endereço e o bairro.
Notação: A  B, A  C, então A  BC

Transitividade
CPF  DataNascimento e DataNascimento  Idade, então CPF  Idade
Se com um número de CPF, eu encontro a data de nascimento de uma pessoa e com a data
de nascimento eu encontro a idade, então com o número do CPF eu posso encontrar a idade de
uma pessoa.
Notação: A  B e B  C, então A  C
Pseudotransitividade
CPF  código-aluno e código-aluno, mês  mensalidade, então CPF, mês  mensalidade
Se com um número de CPF, você encontra o código do aluno e com o código do aluno e o
mês você verifica a situação da mensalidade naquele mês, então com o número do CPF e o mês
você pode encontrar a situação da mensalidade (débito ou não) naquele mês.
Notação: A  B e BC  D então AC  D
Em alguns casos, pode existir a dependência multivalorada. Essa dependência ocorre
quando o valor de um atributo determina um conjunto de valores de outro atributo.
Exemplo:
CPF  Nome: um único CPF determina um único nome.
CPF Dependentes: um único CPF determina vários dependentes.
A dependência multivalorada é representada por:
AB
• A multidetermina B.
• B é multidependente de A.
6. NORMALIZAÇÃO
Ted Codd apresentou, em 1972, os primeiros trabalhos que aplicavam conceitos de nor-
malização. Mas do que se trata a normalização?
A normalização é um processo destinado a avaliar e corrigir estruturas e tabelas, de modo
a reduzir as redundâncias de dados e, consequentemente, a probabilidade de anomalias. O
processo de normalização envolve a designação de atributos a tabelas com base no conceito de
determinação.
É função da normalização atuar como uma uma espécie de filtro sobre as entidades e os
relacionamentos, eliminando alguns elementos sem causar perda de informação. No decorrer
deste estudo, você observará como isso é realizado por meio das formas normais, as quais
foram introduzidas para atuar nos casos em que a informação se encontra disponível para ser
tratada, deixando os dados mais organizados dentro de um banco de dados.
Observe, a seguir, o que poderá ser evitado quando aplicada a normalização:
1) grupos repetitivos (atributos multivalorados) de dados;

2) variação temporal de certos atributos, dependências funcionais totais ou parciais em
relação a uma chave concatenada;
3) redundâncias de dados desnecessárias;
4) perdas acidentais de informação;
5) dificuldade na representação de fatos da realidade observada;
6) dependências transitivas entre atributos.
O objetivo da normalização não é eliminar todas as inconsistências, e, sim, controlá-las.
Como dissemos, a normalização tem sua atuação por meio das formas normais. Os pri-
meiros estágios do processo de normalização são: primeira forma normal (1NF), segunda forma
normal (2NF) e terceira forma normal (3NF). Nesses três primeiros estágios, sob o ponto de vista
estrutural, a forma normal maior apresenta-se melhor sobre sua antecessora; logo, a 3NF é me-
lhor que a 2NF, que, por sua vez, é melhor que a 1NF.
Embora a normalização seja de grande importância para o Projeto de Banco de Dados,
não se deve assumir que o nível mais alto seja sempre o mais adequado. O êxito de um projeto
dá-se mediante a análise da demanda do usuário cujo objetivo é promover um desempenho
satisfatório no acesso aos dados.
Necessidade de normalização
Para melhor compreensão do processo de normalização, nosso modelo de estudo será
baseado em um banco de dados de uma empresa de construção, que tem as seguintes especi-
ficidades:
1) Gerencia vários projetos simultaneamente.
2) Cada projeto possui um nome e números próprios, e funcionários designados à sua
execução.
3) Cada funcionário possui um número, nome e classificação de seu cargo.
4) Cobra de seus clientes pelas horas gastas em cada contrato.
5) A taxa de cobrança horária depende da posição do funcionário alocado (valor de um
engenheiro é diferente do valor de um técnico).
6) Um funcionário pode estar alocado a um ou mais projetos simultaneamente.
Inicialmente, teremos uma tabela que contém os dados dos projetos e funcionários. Os
dados constituirão um relatório posterior. Veja a estrutura dessa tabela na Figura 1:

Figura 1 Exemplo de layout do relatório.
Conforme podemos observar, o modelo dessa tabela não se enquadra às melhores prá-
ticas já estudadas para a modelagem de um banco de dados. São encontradas as seguintes
deficiências:
1) O número de projeto (PROJ_NUM) destina-se, aparentemente, a constituir uma chave
primária (ou parte de uma), mas contém valores nulos.
2) As entradas induzem a inconsistência de dados: o cargo Eng. Eletricista, na coluna
JOB_CLASS, poderá ser inserido de distintas formas a cada cadastro, tais como: Elect.
Engineer, El. Eng, entre outras.
3) A tabela apresenta redundância de dados que originam as seguintes anomalias:
a) Anomalias de atualização: caso necessário, modificar o valor de JOB_CLASS para
o funcionário cujo EMP_NUM = 105 será muito trabalhoso (pensando em uma
base de dados com potenciais milhares de registros), pois todos os registros em
que o funcionário aparece deverão ser alterados.
b) Anomalias de inserção: considerando-se a necessidade de inserção de um novo
funcionário em um dado projeto, se este não tiver sido cadastrado, será necessá-
ria a criação de um projeto "fantasma" para concluir a entrada de dados.
c) Anomalias de exclusão: imaginemos a situação em que um funcionário está asso-
ciado a apenas um projeto: caso este deixe a empresa e seus dados sejam excluí-
dos, as informações pertinentes ao projeto também serão perdidas.
Embora tenhamos detectado várias deficiências de cunho estrutural na tabela em ques-
tão, ela parece atender as necessidades de geração de um relatório.
7. PROCESSO DE NORMALIZAÇÃO
Neste tópico, aprenderemos os procedimentos e as etapas necessárias à aplicação das
melhores práticas de normalização para a tabela da Figura 1. O objetivo da normalização é ga-
rantir que todas as tabelas atendam ao conceito de relações bem estabelecidas, ou seja, que
tenham as seguintes características:
1) Cada tabela deve apresentar um único assunto: uma tabela de disciplina deverá con-
ter apenas as informações pertinentes à disciplina.
2) Nenhum item de dado deverá ser armazenado de forma desnecessária em mais de
uma tabela: como dito anteriormente, a redundância, caso não possa ser evitada,
deve ser minuciosamente controlada.
3) Todos os atributos não primários pertinentes à tabela deverão ser dependentes da
chave primária: isso garante a identificação exclusiva dos dados.
4) Todas as tabelas deverão estar livres das anomalias, de modo a garantir a integridade
e a consistência dos dados.
Para que possamos atender a todas as características elencadas, devemos proceder ao
processo de normalização, o qual passa por etapas, de modo a atingir formas normais sucessi-
vamente superiores. Porém, é importante lembrar que nem sempre o uso de formas normais
elevadas é a melhor opção.
As formais normais mais comuns estão descritas na Tabela 1:
Tabela 1 Formas normais.

FORMA NORMAL CARACTERÍSTICA
Primeira forma normal (1NF) Formato de tabela, sem grupos repetidos e com PK identificada
Segunda forma normal (2NF) 1NF sem dependências parciais
Terceira forma normal (3NF) 2NF sem dependências transitivas
Forma normal de Boyce-Codd (BCNF) Todo determinante é uma chave candidata (caso especial de 3NF)
Quarta forma normal (4NF) 3NF sem dependências multivaloradas independentes
Do ponto de vista do modelador dos dados, o objetivo da normalização é assegurar que

todas as tabelas estejam, ao menos, em conformidade com a terceira norma formal. Existem
formas de níveis superiores a 3NF, as quais se destinam a estudos teóricos acerca da normaliza-
ção ou aplicações cuja finalidade seja muito específica, e que muito provavelmente não serão
encontradas em ambientes comerciais.
Conversão para a primeira forma normal (1NF)

De acordo com o modelo relacional, os dados de uma tabela ou conjunto de tabelas em
que todos os seus valores chave sejam identificadores exclusivos (por exemplo, os dados apre-
sentados na Figura 1) não devem ser armazenados da maneira ora exposta, caracterizando um
aninhamento de tabelas.
Uma relação está na primeira forma normal se todos os seus atributos são monovalora-
dos e atômicos. Atributos atômicos são atributos indivisíveis, ou seja, não podem ser decom-
postos em unidades.
Ao observar a Figura 1, encontramos dados que compõem grupos de repetição, os quais
consistem em um grupo de entradas do mesmo tipo para qualquer ocorrência única de atributo
de chave. Verifica-se que na tabela apresentada pela Figura 1, o projeto Evergreen (PROJ_NUM
= 15) mostra cinco entradas em um dado ponto.

A normalização da tabela permitirá a redução das redundâncias. Se verificada a existência

de grupos de repetição, estes devem ser eliminados, de modo a assegurar que cada linha (tupla)
defina uma única entidade.
A seguir, procederemos às etapas necessárias para a adequação à primeira forma normal.
1) Eliminar grupos de repetição: os dados nulos devem ser eliminados, de modo que
cada valor de repetição contenha um valor de dados adequado. Esta alteração fará
com que a tabela adquira a forma indicada na Figura 2:
Nome da Tabela: RPT_FORMA_1NF

CHG_
PROJ_NUM PROJ_NAME EMP_NUM EMP_NAME JOB_CLASS HOURS
HOUR
15 Evergreen 103 June E. Smith Eng. Eletricista 84,50 23,8
15 Evergreen 101 John G. News Projetista de Banco de Dados 105,00 19,4
15 Evergreen 105 Alice K. Johnson Projetista de Banco de Dados 105,00 35,5
15 Evergreen 106 William Smithfield Programador 35,75 12,6
15 Evergreen 102 David H Senior Analista de Sistemas 96,75 23,5
18 Amber Wave 114 Annelise Jones Projetista de Aplicações 48,10 34,22
18 Amber Wave 118 James J. Frommer Suporte Geral 18,36 51,22
18 Amber Wave 104 Anne K. Ramoras Analista de Sistemas 96,75 78,31
18 Amber Wave 112 Darlene M. Smithson Analista SSD 45,95 32,45
22 Rolling Tide 105 Alice K. Johnson Projetista de Banco de Dados 105,00 15,32
22 Rolling Tide 104 Anne K. Ramoras Analista de Sistemas 96,75 34,65
22 Rolling Tide 113 Delvert K. Joenbrood Projetista de Aplicações 48,10 67,88
22 Rolling Tide 111 Geoff b. Wabash Suporte Escriturário 26,87 23,41
22 Rolling Tide 106 William Smithfield Programador 35,75 23,1
25 Starflight 107 Maria D. Alonzo Programador 35,75 11,5
25 Starflight 115 Travis B. Bawangi Analista de Sistemas 96,75 98,76
25 Starflight 101 John G. News Projetista de Banco de Dados 105,00 47,89
25 Starflight 114 Annelise Jones Projetista de Aplicações 48,10 43,45
25 Starflight 108 Ralph B. Washington Analista de Sistemas 96,75 23,56
25 Starflight 118 James J. Frommer Suporte Geral 18,36 58,65
25 Starflight 112 Darlene M. Smithson Analista SSD 45,95 45,62
Figura 2 Tabela na 1NF.
2) Identificar chave primária: a mudança de aspecto da tabela apresentada na Figura 2

nos permite constatar que PROJ_NUM não é um bom valor para chave primária, pois
esse número identifica o número do projeto e não agrega exclusividade aos demais
atributos. Uma chave primária adequada, que assegure exclusividade aos demais atri-
butos, é a combinação de PROJ_NUM e EMP_NUM. Uma vez conhecido o número
de identificação do projeto e do empregado, todos os demais atributos tornam-se
exclusivos.
3) Identificar todas as dependências: a identificação da PK na Etapa 2 significa que, a par-
tir dessas identificações, podemos encontrar as dependências funcionais, por exem-
plo:
PROJ_NUM, EMP_NUM à PROJ_NAME, EMP_NAME, JOB_CLASS, CHG_HOUR, HOURS
Verifica-se que PROJ_NAME, EMP_NAME, JOB_CLASS, CHG_HOUR, HOURS são de-
pendentes da combinação PROJ_NUM e EMP_NUM, ou seja, são:
PROJ_NUM à PROJ_NAME e EMP_NUM à EMP_NAME, JOB_CLASS, CHG_HOUR.
Neste novo modelo, observa-se o emprego da 1NF, que descreve um formato de tabela
no qual:
• Todos os atributos de chave estão definidos.
• Não há grupos de repetição na tabela. Ou seja, cada intersecção de linha/coluna con-
tém um e somente um valor, não um conjunto de valores.
• Todos os atributos são dependentes de chave primária.
Depois de realizados os ajustes, podemos concluir que:
• Os atributos de chave primária são: PROJ_NUM e EMP_NUM.
• Existem dependências parciais: é necessário conhecer apenas o PROJ_NUM para que
se determine PROJ_NAME, ou seja, este é dependente apenas de uma parte da chave
primária. Da mesma forma, EMP_NAME, JOB_CLASS, CHG_HOUR e HOURS são depen-
dentes apenas de EMP_NUM.
Embora as dependências parciais não sejam recomendadas, muitas vezes seu uso é feito
baseando-se no desempenho. Contudo, tais dependências devem ser aplicadas no modelo de
banco de dados com muita precaução, pois uma tabela que contenha dependências parciais ain-
da está sujeita a redundâncias de dados e, portanto, a várias anomalias. As redundâncias, neste
caso, são inevitáveis, visto que as entradas das linhas exigirão duplicidade dos dados, podendo
ocorrer digitações inconsistentes com o padrão definido inicialmente e ocasionar a violação de
integridade.
Conversão para a segunda forma normal (2NF)

Conforme demonstrado na Tabela 1, o emprego da segunda forma normal dá-se quando a
1NF possui chave primária composta. Utilizando-se a primeira forma normal, e quando a tabela
resultante possuir chave primária com apenas um atributo, a tabela está automaticamente na
segunda forma normal (2NF).
A conversão da 1NF para 2NF é bastante simples, conforme segue:
1) Apresentar cada componente de chave em uma linha separada e, em seguida, escre-
ver a chave original (composta) na última linha, por exemplo:
PROJ_NUM
EMP_NUM
PROJ_NUM EMP_NUM
2) Cada um dos componentes se tornará a chave primária de uma nova tabela, ou seja,
a tabela original será dividida em três tabelas: PROJETO, FUNCIONARIO e DESIGNA-
CAO.
3) Distribuir os atributos dependentes: determinar os atributos interdependentes; logo,
as três novas tabelas serão compostas do seguinte modo:
PROJETO (PROJ_NUM, PROJ_NAME)

FUNCIONARIO (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR)
DESIGNACAO (PROJ_NUM, EMP_NUM, ASSIGN_HOURS)
Veja, na Figura 3, a nova estrutura das tabelas.

Figura 3 Divisão das tabelas para emprego da 2NF.
A tabela DESIGNACAO, exibida na Figura 3, teve sua formação porque o número de ho-
ras gastas em cada projeto por cada funcionário é dependente tanto de PROJ_NUM como de
EMP_NUM: essas horas devem ser alocadas nesta tabela, no atributo ASSIGN_HOURS.
A tabela DESIGNACAO contém uma chave primária composta pelos atributos PROJ_NUM e
EMP_NUM. Qualquer atributo que faça parte, pelo menos, de uma chave é conhecido como atributo
primário ou atributo-chave. Portanto, PROJ_NUM e EMP_NUM são atributos primários (ou chave).
A partir da quebra da tabela originária (Figura 2), a maioria das anomalias ora discutidas
foi eliminada.
Caso queira-se adicionar, alterar ou excluir algum registro de PROJETO, basta realizar a
ação junto à respectiva tabela, tendo impacto apenas no registro alterado; todas as demais in-
formações correlacionadas a este projeto permanecerão íntegras e consistentes.
Como já discutido anteriormente, só existe ocorrência de dependência parcial a partir da
existência de chave primária composta por vários atributos da tabela; a tabela que possui ape-
nas um atributo como chave primária já está enquadrada na 2NF.
Conversão para a terceira forma normal (3NF)

Similar ao processo de normalização, um modelo, antes de ser convertido a 3NF, deve,
primeiro, estar enquadrado na 2NF.
Existe uma forma normal mais restritiva do que a terceira forma normal, que é a forma
normal de Boyce-Codd (BCNF), a qual foi proposta como uma forma mais simples que a 3NF. A
BCNF é considerada mais restrita, pois, à medida que toda relação está na BCNF, também estará
na 3NF; entretanto, o inverso não é verdadeiro.
O projeto de um banco de dados relacional deve empenhar-se, preferencialmente, em

alcançar a 3FN ou BCNF para todo esquema da relação. Alcançar o status de normalização so-
mente na 1FN ou na 2FN não é considerado adequado, uma vez que essas formas foram desen-
volvidas como caminho para a 3FN.
Baseada no modelo expresso pela Figura 3, a conversão para esta forma normal segue os
estágios propostos, a fim de que esta ocorra facilmente:
1) Identificar todos os novos determinantes: o determinante é qualquer atributo cujo
valor determine outros valores na mesma linha. No modelo de conformidade com a
Figura 3, existe apenas um determinante: JOB_CLASS.
2) Identificar os atributos dependentes: discriminar os atributos dependentes de cada
determinante descrito na Etapa 1 (da adequação da primeira forma normal); assim,
teremos:
JOB_CLASS à CHG_HOUR
Esta etapa fornece informações para a constituição de uma nova tabela. Sabe-se que
um nome deve representar seu conteúdo e função; portanto, nomearemos de CARGO.
3) Remover os atributos dependentes das dependências transitivas: deveremos provi-
denciar a remoção do atributo CHG_HOUR da tabela FUNCIONARIO; assim, teremos
em FUNCIONARIO:
JOB_CLASS à CHG_HOUR
Podemos observar que o atributo JOB_CLASS permanece na tabela FUNCIONARIO,
fazendo papel de chave estrangeira (FK). Neste novo arranjo, temos as seguintes de-
pendências, representadas pela Figura 4:
Figura 4 Resultado da conversão para a 3NF.
Conforme demonstrado na Figura 4, a conversão para a terceira forma normal originou

quatro tabelas: PROJETO, FUNCIONARIO, CARGO e DESIGNACAO.
Estudo de caso de normalização

Como exemplo de estudo de caso de normalização, observe a relação NOTA_FISCAL:
• VENDAS(CodForn, Nome, Status, Cidade, CodPeça, Preço, Qtde, Valor).
Veja, a seguir, como seria a tabela da relação anterior:

Tabela 2 Estudo de caso de normalização.

CODFORN NOME STATUS CIDADE CODPEÇA PREÇO QTDE VALOR
F1 Fornecedor 1 20 Londres P1 R$ 10,00 300 R$ 3.000,00
F1 Fornecedor 1 20 Londres P6 R$ 5,00 100 R$ 500,00
F2 Fornecedor 2 10 Paris P1 R$ 10,00 300 R$ 3.000,00
Fonte: adaptado de Rangel (2012) apud Carvalho (2006).
Teremos, assim, algumas anomalias, a saber:

De Inserção:
• Nenhuma localização de fornecedor pode ser inserida até que este forneça, pelo me-
nos, uma peça.
• Toda vez que uma peça for fornecida, será preciso repetir os dados do fornecedor.
De Alteração:
• O valor do campo CIDADE aparece várias vezes na tabela, o que aumenta a probabili-
dade de erros. Assim, se o fornecedor 1 mudar para 'AMSTERDÃ', teremos de atualizar
vários registros.
• Se cuidados não forem tomados, uma ocorrência do Fornecedor 1 poderá ocorrer em
Londres e outra, em Amsterdã. O mesmo problema sucede com os campos 'NOME' e
'STATUS'.
• O campo VALOR apresenta outra anomalia: ele é calculado pela multiplicação de PRE-
ÇO e QTDE. Se atualizarmos o preço unitário, teremos de atualizar, também, o VALOR.
A anomalia ocorre uma vez que tal atualização possa ser esquecida.
De Exclusão:
• Se todos os registros de um fornecedor precisam ser apagados, serão excluídas não
apenas suas relações com as peças, mas também a informação de que o fornecedor
está localizado em uma determinada cidade.
O que é a decomposição sem perdas?

A decomposição sem perdas é o processo de normalização que envolve a quebra ou a
decomposição das relações que precisam ser normalizadas em relações menores, de forma que
possa ser reversível e que nenhuma informação seja perdida.
Veja a seguinte relação:
• NOTA_FISCAL (NumNota, Data, CodForn, Nome, Telefone, Endereço, CodItem, Cod-
Prod, Produto, Qtde, Preço, TotalItem). Observe sua representação na tabela da Figura
5:

Figura 5 Representação de uma relação.
1FN – Primeira Forma Normal

Na primeira forma normal, os dados devem ser atômicos, ou seja, cada um deve armaze-
nar apenas um valor. Dessa forma:
1) Não são permitidos atributos multivalorados.
2) Não são permitidos atributos repetidos, como Fone1, Fone2, Fone N, por exemplo.
3) Todos os registros da relação devem ser diferentes.
4) Não poderá haver, na Entidade, mais de duas dimensões (Linhas e Colunas).
5) Não é permitido que cada atributo contenha mais de um tipo de dado. Um exemplo
comum de violação é o CPF e o CNPJ, armazenados em um único campo chamado
DOCUMENTO.
Portanto, a tabela visualizada anteriormente ficaria normalizada na 1FN conforme a Figura 6:

Figura 6 Representação de uma relação na 1FN.
2FN – Segunda Forma Normal

A segunda forma normal tem como objetivo a diminuição da redundância e o desagrupa-
mento de informações. Na 2FN, uma tabela representa uma quantidade menor de entidades.
Dessa maneira:
• Para uma relação estar na 2FN, é preciso que ela esteja, primeiro, na 1FN.
• Todo atributo que não faz parte da chave deve ser determinado por todos os atributos
que formam a chave primária. É preciso eliminar, pois, as dependências funcionais par-
ciais.
• Os campos não enquadrados na 2FN devem ser movidos para uma nova tabela, que
também deverá ser normalizada.
Na relação NOTA_FISCAL, os atributos NUMNOTA e CODITEM formam a chave primária;
contudo, NUMNOTA define os campos DATA, CODFORN, NOME, TELEFONE e ENDERECO, ou
seja, para definir esses campos não é necessário saber o CODITEM. Portanto, temos uma depen-
dência funcional parcial da chave primária. A solução é a divisão dessa tabela em duas, como
demonstrado na Figura 7:


Conforme observamos na tabela da Figura 7, temos, agora, duas relações: NOTA_FISCAL e

NOTA_FISCAL_ITEM, que ficam da seguinte maneira:
• NOTA_FISCAL(NroNota, Data, CodForn, Nome, Telefone, Endereço).
CE
• NOTA_FISCAL_ITEM(NroNota, CodItem, CodProd, Produto, Qtde, Preço, TotalItem).
3FN – Terceira Forma Normal

A terceira forma normal tem o mesmo objetivo da 2FN, ou seja, objetiva diminuir a redun-
dância das informações. Para que uma relação esteja na 3FN, é necessário:
1) Estar, antes, na 2FN.
2) Identificar e eliminar a transitividade.
3) Determinar, de forma não transitiva pela chave primária, todo atributo que não fizer
parte da chave; em outras palavras, todo atributo que não fizer parte da chave deve
ser determinado apenas pela chave primária.
4) Mover os campos não enquadrados na 3FN para uma nova relação, que também de-
verá ser normalizada.
Aplicando esses fundamentos sobre as duas relações que temos até o momento, encon-
tramos os seguintes problemas:
Para a relação NOTA_FISCAL

Há transitividade na determinação dos campos NOME, TELEFONE e ENDEREÇO, porque
CODFORN é determinado pelo NRONOTA, e esses três campos são determinados por CODFORN.
A solução é dividir essa relação em duas:
• NOTA_FISCAL(NroNota, Data, CodForn).
• FORNECEDOR(CodForn, Nome, Telefone, Endereço).
Para a relação NOTA_FISCAL_ITEM

Existe transitividade para os campos PRODUTO e PREÇO, que são determinados por meio
do CODPROD, o qual, por sua vez, é determinado pela chave primária da relação composta pelos
campos NRONOTA e CODITEM.
Há transitividade no campo TOTALITEM, que é determinado pela multiplicação dos atribu-
tos QTDE e PREÇO.
Observe que a solução para essa relação é a sua divisão em outras duas:
• PRODUTO(CodProd, Produto, Preço).
• NOTA_FISCAL_ITEM(NroNota, CodItem, CodProd, Qtde).

Note que o campo TOTALITEM foi removido, pois, conforme descrito anteriormente, ele
pode provocar anomalias de inserção e de alteração, por se tratar de um atributo derivado.
Veja, a seguir, como ficam as relações depois da normalização concluída:
1) FORNECEDOR(CodForn, Nome, Telefone, Endereço).
2) PRODUTO(CodProd, Produto, Preço).
CE
3) NOTA_FISCAL(NroNota, Data, CodForn)
CE CE
4) NOTA_FISCAL_ITEM(NroNota, CodItem, CodProd, Qtde)
8. FATORES A SEREM CONSIDERADOS NO PROJETO FÍSICO DE BANCO DE DA-

DOS RELACIONAL
O desempenho é um fator que deve ser levado em consideração desde a fase inicial do
projeto do banco de dados. No entanto, você poderá fazer modificações para melhorar o de-
sempenho mesmo depois de ter iniciado a construção do banco de dados.
O Projeto Físico de Banco de Dados é uma das etapas mais importantes da construção do
banco de dados. Ele define qual é a estrutura física a ser adotada e como será realizado o arma-
zenamento e acesso aos arquivos do banco de dados, a fim de obter o melhor desempenho das
aplicações. Esse projeto define parâmetros físicos de acesso ao banco de dados, procurando aper-
feiçoar a performance do sistema como um todo.
As opções de organização e caminhos de acesso aos dados variam em função do SGBD
escolhido para a criação do banco de dados.
Alguns aspectos como tempo de resposta, alocação de espaço e throughput de transações
devem ser analisados na definição do projeto físico.
O tempo de resposta é o tempo transcorrido entre submeter uma transação do banco de
dados para executar e receber uma resposta. A alocação de espaço é o quanto de espaço de ar-
mazenamento é utilizado, tanto pelos arquivos do banco de dados, quanto pelas suas estruturas

de caminhos de acesso aos dados em disco. O throughput de transações é o número médio de

transações que podem ser processadas por minuto. Todos esses aspectos têm influência direta
na carga de trabalho (conjunto de consultas e atualizações ponderadas por suas frequências de
ocorrência) a que será submetido o banco de dados.
Por exemplo, na descrição da carga de trabalho, alguns itens devem ser especificados,
como:
• metas de desempenho para cada tipo de consulta de atualização;
• listas de atualizações e suas frequências;
• listas de consultas e suas frequências.
Para cada atualização, é necessário identificar:
• quais atributos têm condições de seleção e junção e quão necessários eles são;
• qual o tipo de atualização (INSERT, DELETE ou UPDATE) e a relação atualizada;
• quais os campos que são modificados com comando UPDATE.
Para cada consulta, você também deve identificar:
• quais relações são acessadas;
• quais atributos possuem condições de seleção ou de junção e quão necessários eles
são;
• quais atributos são obtidos usando SELECT.
Com essas informações em mãos, você poderá ajustar os parâmetros, as configurações e
as estruturas de um sistema de banco de dados à necessidade de uma determinada carga de
trabalho.
Para tanto, os atuais produtos de bancos de dados oferecem entre dezenas e centenas de
parâmetros e configurações que podem ser ajustados para alcançar um funcionamento mais
eficiente. O ajuste desses parâmetros é complexo, tanto pela necessidade de compreensão dos
algoritmos que são utilizados pelo sistema, quanto pela possibilidade de inter-relações entre os
ajustes.
Tunning de banco de dados

O tunning de banco de dados é o ajuste orientado e contínuo no projeto físico do banco
de dados de forma a melhorar o desempenho. Ocorre, quando necessário, logo após o banco
de dados entrar em operação.
Sabe-se que uma das principais funções de um sistema de banco de dados é fornecer res-
postas aos usuários finais dentro de um tempo adequado, ou seja, o menor possível. A interação
do usuário final com o SGBD dá-se mediante o seguinte processo:
1) a aplicação do usuário final, ao lado do cliente, gera uma consulta;
2) a consulta é enviada ao SGBD, no servidor;
3) o SGBD executa a consulta;
4) o SGBD envia a coleção de dados resultante para a aplicação.
Para prover um bom tempo de resposta ao usuário, a utilização de tunning é bastante vi-
ável, sendo seu objetivo melhorar o desempenho das aplicações, diminuir o tempo de resposta
de consultas e transações e melhorar o throughput geral das transações.
Para o processo de tunning, são considerados os seguintes itens para ajuste:
1) tamanho de tabelas individuais;

2) quantidade de execução de consultas/transações em um período;
3) tempo necessário para execução de consultas/transações;
4) dados sobre localização de tablespaces, índices e buffers;
5) tempo de atividade de dispositivos de I/O (dispositivos de entrada/saída).
É importante mencionar que o processo de tunning, dadas as variáveis que interferem em
sua execução, é bastante complexo, pois como medir se um tempo é bom ou não? É sempre
mais fácil identificar o mau desempenho do que o bom. O ideal é ouvir as queixas dos usuários
finais quanto à lentidão de retorno das consultas.
A medição dos tempos demandados por cada consulta é, também, bastante complicado,
pois o tempo pode ser apresentado como satisfatório em determinado momento e mostrar-
-se ineficaz em outro. Para que se possa prover sempre os melhores resultados no quesito de
performance do SGBD, o desempenho geral deve ser estritamente monitorado e passar por
sintonização regulares.
A sintonização pode ser entendida como ajustes (também conhecidos como tunning) no
âmbito do SGBD que infiram nos tempos de execução dos procedimentos a serem executados.
A sintonização de desempenho de banco de dados refere-se a um conjunto de atividades, pro-
cedimentos e projetos cujo objetivo é reduzir o tempo de resposta de um sistema de banco de
dados, ou seja, prover meios para que a consulta seja processada pelo SGBD no período mínimo
de tempo.
O tempo necessário para que uma consulta retorne um conjunto de resultados depende
de vários fatores, os quais são muito diversificados e amplos em função do ambiente e do for-
necedor do SGBD em questão. Os fatores principais que inferem no desempenho de um SGBD
de modo restritivo são: a capacidade de processamento da CPU, a memória principal disponível
(RAM) e a taxa de transmissão de entrada/saída (disco rígido e rede).
Quando se deparar com algum problema, é fundamental que você, como projetista de
banco de dados, faça algumas perguntas, como:
• Como evitar bloqueios excessivos, aumentado a concorrência entre transações?
• Como aperfeiçoar o tamanho do buffer e o agendamento de processos?
• Como alocar recursos (memória RAM, discos e processos) para utilização mais eficien-
te?
Baseado em informações e aspectos necessários ao banco de dados, o administrador do
banco de dados pode ajustar o desempenho realizando várias modificações nos parâmetros do
SGBD, tais como: alterar o hardware para uma tecnologia recente capaz de resolver alguns gar-
galos de processamento, utilizar outro sistema operacional ou aumentar o tamanho do buffer.
A boa sintonização de um sistema exige uma abordagem holística (todos os aspectos do
SGBD de forma global), ou seja, todos os fatores devem ser verificados para garantir que cada
um opere em seu nível ideal e tenha recursos suficientes para minimizar a ocorrência de garga-
los. Neste sentido, o projeto de banco de dados é um fator de grande relevância para um melhor
desempenho, pois não há sintonização refinada que seja boa o suficiente para fazer com que um
banco de dados mal projetado funcione tão bem quanto um projetado adequadamente.

Gargalos de processamento de consultas

O principal objetivo do processamento de consultas é executá-la do modo mais rápido
possível com a quantidade mínima de recursos. Para que um SGBD processe uma consulta é
exigido que este se desmembre em uma série de operações de entrada/saída independentes a
serem executadas de modo colaborativo.
A complexidade da consulta faz com que as operações a serem realizadas pelo SGBD sejam
também mais complexas e isso, provavelmente, acarretará no aumento de gargalos. O gargalo
de processamento de consultas é um atraso introduzido no processamento de uma operação
E/S, e faz com que o sistema em geral fique mais lento. Deste modo, quando uma operação
complexa é executada e gera-se um gargalo, mesmo as operações de relativa simplicidade serão
afetadas, pois todo o sistema estará comprometido.
Em um SGBD existem cinco componentes que normalmente causam os gargalos:
1) CPU: a capacidade de processamento da CPU deve corresponder à carga de trabalho
esperada do sistema. A alta utilização de CPU pode indicar que a velocidade do pro-
cessador é muito baixa perante a demanda de utilização do SGBD, embora a utilização
massiva de recursos possa ser decorrente de outros fatores, tais como: defeitos de
componentes, memória RAM insuficiente, driver de dispositivo mal escrito. O fato
é que o gargalo da CPU não afetará no desempenho de uma consulta apenas, ou do
SGBD, mas implicará o mau desempenho de todo o sistema em geral.
2) Memória RAM: o SGBD aloca memória para uma utilização específica, como cache
de dados e de SQL. Como a memória é compartilhada por todo o sistema em questão
(sistema operacional e demais aplicativos), se ela for insuficiente, a competição por
seu uso entre os processos computacionais poderão originar gargalos.
3) Disco rígido: a velocidade do disco é uma causa comum de gargalo, bem como suas
taxas de transferência de dados. As tecnologias modernas têm permitido maior ca-
pacidade de armazenamento do que no passado, mas o espaço em disco é utilizado
pelo sistema como um todo, e não apenas pelo SGBD. Sabe-se que os sistemas ope-
racionais usam espaço em disco para fazer o swap, ou seja, o disco é utilizado como
uma memória virtual, que consiste em copiar áreas da memória RAM para o disco, de
acordo com a necessidade. De modo geral, quanto maiores o espaço para armazena-
mento e as taxas de transferência de dados, menor será a probabilidade de gargalos.
4) Rede: geralmente é o meio utilizado para conectar os clientes (usuários) ao servidor
de banco de dados, permitindo que múltiplos usuários demandem por recursos ao
mesmo tempo. É sabido que as redes têm largura de banda limitada e é compartilha-
da entre todos os clientes; logo, quantidades demasiadas de clientes na rede podem
causar gargalo.
5) Código de aplicação: nem todos os gargalos são oriundos de recursos de hardware. É
comum encontrar códigos mal escritos das aplicações que acessam o banco de dados.
Nenhuma quantidade de codificação poderá fazer com que um banco de dados mal
projetado funcione melhor.
Índices e a otimização de consultas

Os índices são fundamentais para acelerar o acesso aos dados, pois facilitam a busca, a
classificação e a utilização de funções agregadas e operações de junção.
Os índices, que são um conjunto ordenado de valores que contém a chave de índice e os
ponteiros – as IDs para as linhas das tabelas reais –, proporcionam a melhoria do acesso aos da-
dos. Conceitualmente, o índice de dados é semelhante ao índice de um livro comum, e utilizar o
índice em um SGBD é bem similar ao processo do índice de um livro: por meio de uma palavra,
que é a chave deste índice, encontramos a página em que aquele conteúdo é abordado no livro;
no contexto de SGBD, encontramos o ponteiro.
A varredura de índice é mais eficiente do que a varredura completa de uma tabela, pois os
dados no índice são preordenados e sua quantidade geralmente é muito menor. Deste modo, ao
se realizar uma busca, é preferível e aconselhável que se utilize o índice para acessar uma tabela,
e não sua varredura completa.
Se os índices são tão importantes, por que não indexar a tabela toda? A resposta é sim-
ples: não é viável, pois o trabalho que seria despendido pelo SGBD para manter e atualizar todos
os índices seria, certamente, muito mais caro em termos de recursos e tempo, do que a sua não
utilização.
Quando se deve criar um índice?

Para responder a esta pergunta, podemos nos basear na esparsidade dos dados da coluna
que se deseja indexar. A esparsidade refere-se ao número de valores distintos que uma coluna
poderá abrigar. Por exemplo: em uma tabela fictícia que armazena dados de FUNCIONARIOs,
temos que:
FUNCIONARIOS (CPF, NOME, SEXO)
Podemos observar que na tabela FUNCIONARIO, o atributo SEXO será pouco esparso, pois
conterá poucos identificadores relativos ao sexo do indivíduo; já o atributo CPF apresenta con-
dições de ser classificado no conceito de esparsividade, pois o CPF será único para cada funcio-
nário (realidade presumida e esperada).
A maioria dos SGBDs utiliza as seguintes estruturas para compor seus índices:
• Hash: utiliza-se um algoritmo para criar um valor de hash a partir de uma coluna de
chave. Esse valor aponta para uma entrada em uma tabela de hash que, por sua vez,
aponta para a localização real da linha dos dados. Esse tipo de índice é apropriado para
operações de busca simples e rápida.
• Árvore B: é o tipo mais comum de índice, utilizado, especialmente, em tabelas, nas
quais os valores de coluna repetem-se em número relativamente menor de vezes. O
índice de árvore B é uma estrutura de dados ordenada, organizada como uma árvore
descendente.
• Bitmap: utilizado em aplicações de dados warehouse, para tabelas com grande número
de linhas, nas quais um pequeno número de valores de coluna se repete muitas vezes.
Os índices de bitmap tendem a utilizar menos espaço se comparados aos de árvore B,
pois usam bits e não bytes para armazenar os dados.
O índice é um item que pode ser alterado no SGBD. Os índices são objetos de banco de
dados que otimizam a busca e a classificação dos dados e, quando configurados apropriadamen-
te, podem fazer uma enorme diferença no tempo levado para inserir ou extrair dados do banco
de dados. No SQL Server existe uma ferramenta chamada ITW (Index Tunning Wizard), que faz
recomendações de como os índices devem ser criados em um banco de dados para aperfeiçoar
o seu desempenho. As recomendações do ITW serão realizadas de acordo com as cargas de tra-
balho e, por isso, é importante que você prepare com antecedência as informações apropriadas.

unidade:
1) Defina e exemplifique os conceitos a seguir:
a) Dependência funcional.
b) Dependência funcional parcial.
c) Dependência funcional transitiva.
d) Dependência funcional multivalorada.
e) Dependência funcional cíclica.
2) Quais são as principais anomalias que podem ocorrer em uma tabela sem normalização?
3) Quais as formas normais existentes para o processo de normalização? Defina suas principais características.
4) Quais são os cinco componentes que, eventualmente, podem ocasionar gargalos em um banco de dados?
5) Qual é a importância do uso de índices para acelerar os acessos aos dados?
6) Considere a relação R = {A,B,C,D,E}, que possui as seguintes dependências funcionais:

DF1: {A, B} → {C, D}
DF2: D → E
As dependências funcionais especificam que:
DF1: A combinação dos valores de A e B determina, exclusivamente, o valor de C e o valor de D.
DF2: O valor de D determina, exclusivamente, o valor de E.
Em que forma normal está a relação R?
a) Primeira Forma Normal.
b) Segunda Forma Normal.
c) Terceira Forma Normal.
d) Forma Normal de Boyce-Codd.
e) Quarta Forma Normal.
7) Considere a relação R = {A,B,C,D,E,F,G,H}, que possui as seguintes dependências funcionais:
DF1: {A,B} → C
DF2: A → {D,E}
DF3: B → {F,G}
DF4: F → H
As dependências funcionais especificam que:
DF1: A combinação dos valores de A e B determina, exclusivamente, o valor de C.
DF2: O valor de A determina, exclusivamente, o valor de D e o valor de E.
DF3: O valor de B determina, exclusivamente, o valor de F e o valor de G.
DF4: O valor de F determina, exclusivamente, o valor de H.
Analise as afirmativas a seguir:
I. {A,B} é chave candidata da relação R.
II. A decomposição de R em relações na segunda forma normal resultará em três relações.
III. A decomposição de R em relações na terceira forma normal resultará em três relações.
IV. A decomposição de R em relações na terceira forma normal resultará em quatro relações.
Estão corretas apenas as afirmativas:
a) I, II e IV.
b) II e III.
c) I, III e IV.
d) I e IV.
e) II e IV.
8) Normalização é o processo de organização eficiente dos dados dentro de um banco de dados cujos objetivos
são eliminar dados redundantes e garantir que as dependências entre os dados façam sentido. Uma forma
normal é uma regra que deve ser aplicada na construção das tabelas do banco de dados para que estas sejam
bem projetadas.
A forma normal que é violada quando uma relação possui dependências multivaloradas indesejáveis, podendo,
por isso, ser usada para identificar e decompor tais relações, é conhecida por:
a) 1FN.
b) 2FN.
c) 3FN.
d) 4FN.
e) Forma Normal de Boyce-Codd (FNBC).
Gabarito
6) b.
7) a.
8) d.
10. CONSIDERAÇÕES
Nesta unidade, você teve a oportunidade de estudar o significado de dependência fun-
cional, o qual deverá ser utilizado desde o início do projeto para verificar as dependências dos
dados, auxiliando, assim, a otimização das consultas aos dados.
Ao conhecer a dependência que existe entre os atributos, você pôde observar que a nor-
malização induz o desenvolvedor a definir com precisão os dados realmente úteis e necessários
ao sistema, com refinamentos sucessivos das tabelas que eliminarão redundâncias, ambiguida-
des, relações duplicadas e anomalias de atualização.
Com o estudo desta unidade, é possível compreender os fatores relativos ao desenho de
um banco de dados focado em boa performance e os cuidados necessários para a manutenção
da performance com as políticas de tunning.
A próxima unidade terá como objetivo gerar a documentação de projeto de banco de da-
dos. Sua apresentação final do projeto será baseada em toda a teoria estudada até o momento.
11. E-REFERÊNCIA
Site pesquisado
RANGEL, A. L. Normalização. Disponível em: <https://sites.google.com/site/alexandrelrangel/Home/bancos-de-dados-i/BD1-E-
NormalizaÃ§Ã£o.pdf?attredirects=0&d=1>. Acesso em: 22 nov. 2012.
TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J.E. Apostila Introdução a banco de dados. São Paulo: DCC-IME-USP, 2005. Disponível em:
<http://www.ime.usp.br/~jef/apostila.pdf>. Acesso em: 09 out. 2012.

CARVALHO, B.F. Normalização -Técnicas e Conceitos. 6. ed. Rio de Janeiro: SQL Magazine.DevMedia Editora, 2006.
DATE, C. J.; Introdução a Sistemas de Banco de Dados. 8. ed. Trad. Daniel Vieira. Rio de Janeiro: Elsevier, 2003.

ROB, Peter. CORONEL, Carlos. Sistemas de Banco de Dados – projeto, implementação e administração. 8 ed. São Paulo: Cengage
Learning: 2011.
TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J.E. Apostila Introdução a banco de dados. São Paulo: DCC-IME-USP, 2005. Disponível em:
<http://www.ime.usp.br/~jef/apostila.pdf>. Acesso em: 09 out. 2012.
Gerenciamento de Transações
e Controle de Concorrência
1. OBJETIVOS
• Conhecer e definir transação.
• Conceituar os sistemas de processamento de transação.
• Aplicar as principais técnicas de controle de concorrência.
2. CONTEÚDOS
• Definição de transação.
• Tipos de falhas com operações de transação.
• Estados de uma transação.
• Propriedades das transações: ACID.
• Planos de execução das transações.
• Técnicas de controle de concorrência.

guir:
1) A partir desta unidade, estudaremos os principais conceitos de processamento de
transações. Conheceremos conceitos e técnicas relacionados ao controle de concor-
rência, recuperação de banco de dados e banco de dados distribuído. Portanto, fique
atento ao conteúdo que será estudado e, caso tenha dúvida, entre em contato com
seus colegas de curso ou seu tutor.
2) É importante que você estude a Unidade 4, pois é nela que se encontram os coman-
dos da linguagem de consulta SQL.
3) Se tiver dúvidas sobre as restrições de integridade, assunto que retomaremos nesta
unidade, volte ao conteúdo estudado na Unidade 3, tópico Restrições de Integridade
sobre Relações. Esses são conceitos importantes e devem ser bem compreendidos.
4) Concentre-se na definição de transação, os principais tipos de falhas oriundas das
transações, estados de uma transação etc.
5) É muito importante que você também abstraia o conceito e significado das proprieda-
des de uma transação (ACID): atomicidade, consistência, isolamento e durabilidade.
Até o momento, estudamos os conceitos fundamentais relacionados aos bancos de dados.
Vimos que existem três modelos: conceitual, lógico e físico.
Além disso, você aprendeu como elaborar o modelo de dados em nível conceitual, ao
criar o diagrama entidade-relacionamento. Você pôde compreender que esse modelo deve ser
mapeado para o modelo lógico e estudou como normalizar as relações e tratar as dependências
funcionais. Por fim, compreendeu que o modelo lógico dá origem ao modelo físico, em que o
banco de dados é criado no computador, por meio de um Sistema Gerenciador de Banco de
Dados.
Para continuar o nosso estudo, trataremos, nesta unidade, de assuntos relacionados aos
dados que já estão armazenados nos bancos de dados. Ou seja, estudaremos questões sobre
controle de transação, recuperação de dados em caso de falhas, segurança e distribuição de da-
dos. Esperamos que você tenha consolidado o conteúdo estudado anteriormente e tire o maior
proveito possível do que será apresentado a seguir.
Bom, vamos ao nosso estudo!
5. POR QUE GERENCIAR UMA TRANSAÇÃO?

Não podemos pensar em um banco de dados como um sistema único, pois, dificilmente,
ele fica isolado em uma máquina e é acessado por apenas uma pessoa, ou de apenas um lugar.
Ao pensar em banco de dados, devemos ter em mente que informações armazenadas podem
ser acessadas por muitas pessoas, as quais podem, ainda, estar em locais diferentes.
Podemos compreender melhor essa situação se pensarmos em uma instituição financei-
ra, como os muitos bancos que temos espalhados pelo Brasil (considerando apenas o território
nacional). Você pode ter uma conta que foi aberta em determinada agência, mas pode fazer as
operações bancárias a partir de qualquer local em que haja um caixa eletrônico dessa instituição
financeira.
Além disso, pense que você pode ter uma conta com outra pessoa, isto é, duas pessoas
podem fazer as mesmas operações na mesma conta bancária. Se ambas, a partir de lugares di-
ferentes, resolverem fazer um saque, ao mesmo tempo, da mesma conta corrente, quem sacará
primeiro? O usuário poderia receber uma informação incorreta e, muitas vezes, sem lógica.
© U6 - Gerenciamento de Transações e Controle de Concorrência 219
Para que não ocorra esse caos no sistema, existe a transação, que é uma unidade de exe-
cução de programa que acessa e, possivelmente, atualiza vários itens de dados. Ela é delimitada
pelas declarações:
begin transaction e (commit ou rollback)
Segundo Elmasri e Navathe (2005, p. 397), "Sistemas de processamento de transação são

sistemas com grandes bancos de dados e centenas de usuários executando transações concor-
rentes no banco de dados".
A transação está envolvida com os comandos Update, Delete e Insert.
Analisando do ponto de vista do SGBD, uma transação é uma sequência de operações que
são tratadas como um bloco único e indivisível (atômico) quanto à sua recuperação, ou seja, a
execução parcial de transações não é permitida.
O padrão SQL especifica que uma transação começa de modo subentendido. O término da
transação é indicado pelos comandos:
• Commit: quando uma transação termina com sucesso.
• Rollback: quando uma transação termina com um erro.
Atente-se para o fato de que se uma transação terminar em commit, todas as modifica-
ções realizadas dentro dela serão efetivadas; mas se uma transação terminar em rollback, todas
as modificações realizadas dentro dela serão abortadas, conforme demonstra a Figura 1: o ban-
co de dados ficará no mesmo estado em que estava antes da transação ser iniciada. O comando
rollback pode ser emitido, explicitamente, pelo programador, ou automaticamente, pelo SGBD
quando ocorre um erro.
Figura 1 Caminho das transações commit (efetivada) ou rollback (abortada).
O conceito de concorrência está relacionado ao número de usuários que podem usar um

sistema de banco de dados ao mesmo tempo, e trata-se um critério de classificação do banco
de dados. Isso significa que um banco de dados pode ser monousuário, se apenas um usuário,
de cada vez, usar o sistema; ou multiusuário, quando mais de um usuário utiliza, ao mesmo
tempo, o sistema.
Um sistema de reservas de uma empresa aérea usado por centenas de agências de viagem
e balcões de reserva concorrentemente é um exemplo de SGBD multiusuário. Sistemas bancá-

rios, seguradoras, casas de câmbio, supermercados, entre outros, também são operados por
muitos usuários, que submetem transações concorrentes ao sistema.
Diversos usuários podem ter acesso aos bancos de dados. Geralmente, esse acesso ocorre
mediante alguma aplicação usada como interface (front-end) do banco de dados, possibilitando
o acesso simultâneo graças ao conceito de multiprogramação, que permite que o computador
execute diversos programas ao mesmo tempo. Se houver apenas uma unidade central de pro-
cessamento (CPU), ela poderá executar, no máximo, um processo de cada vez. Entretanto, siste-
mas operacionais com multiprogramação executam alguns comandos de um processo, depois
suspendem esse processo e executam alguns comandos do próximo processo, e assim por dian-
te. Portanto, a execução concorrente de processos é, na verdade, intercalada: se existem um
processo A e um processo B, estes serão executados concorrentemente de modo intercalado.
A intercalação possibilita a ocupação da CPU enquanto um processo executa uma opera-
ção de entrada ou saída (I/O), como ler um bloco de um disco, por exemplo. A CPU será chave-
ada para executar outro processo em vez de permanecer ociosa durante esse tempo de I/O. A
intercalação também impede que um processo longo retarde outros processos.
Observe que o fator que permite que muitas pessoas utilizem um único sistema ao mes-
mo tempo está relacionado ao conceito de multiprogramação, que possibilita ao computador
executar mais de um processo simultaneamente. Neste contexto, o sistema operacional executa
alguns comandos de um processo, depois interrompe essa execução e executa alguns comandos
de outro processo, e assim sucessivamente, dando a impressão de que os processos são execu-
tados ao mesmo tempo.
B
B
A A
t1 t2
Figura 2 Dois processos em execuções intercaladas.
Você percebeu como a Figura 2 ilustra claramente a situação?

Veremos, no próximo tópico, alguns conceitos relativos à transação e a importância do
controle de concorrência.
6. TRANSAÇÃO E IMPORTÂNCIA DO CONTROLE DE CONCORRÊNCIA

Para compreendermos melhor toda essa ideia de acessar as mesmas informações de lo-
cais diferentes, e por várias pessoas ao mesmo tempo, veremos alguns conceitos importantes
que nos auxiliarão, por exemplo, a definir transação.
Segundo Elmasri e Navathe (2005, p. 402) a transação "é uma unidade atômica de traba-
lho que, ou estará completa, ou não foi realizada". Ou seja, podemos dizer que uma transação é
um programa que está em execução ou que vai ser executado.
Uma transação envolve operações de inclusão, exclusão, alteração (atualização) e recupe-

ração de dados em um banco de dados, as quais podem ser executadas por meio de um progra-
ma de aplicação ou, ainda, por meio de uma linguagem de consulta, do tipo da SQL (Structure
Query Language ou Linguagem Estruturada de Consulta).
Uma transação é qualquer ação que lê ou grava em um banco de dados e pode ser cons-
tituída por um simples comando de select para buscar uma coleção qualquer, por uma série de
operadores de update relacionados que alterem os valores de atributos de diferentes tabelas,
ou, ainda, por diversos comandos de insert que adicionem linhas a uma ou mais tabelas, poden-
do abranger até a combinação de todos os comandos citados de uma só vez.
A transação é, portanto, uma unidade lógica. Em seu contexto, não são aceitos estágios
intermediários de alguma ação. No processo de venda de uma loja qualquer, por exemplo, é
esperada a utilização de comandos como insert e update. Para a realização de uma venda com
sucesso, todos os comandos pertinentes à sua execução devem ser concluídos com sucesso; na
hipótese de algum deles falhar, toda a transação é desfeita, e os dados não serão modificados
parcialmente, retornando ao seu estado original.
Um banco de dados em estado consistente é aquele em que são satisfeitas todas as res-
trições de integridade de todos os dados. Uma transação bem sucedida altera o banco de dados
de um estado consistente para outro.
Para que a consistência do banco de dados seja garantida, toda e qualquer transação deve
começar com o banco de dados já em um estado considerado consistente. Caso o banco de da-
dos não satisfaça as condições de consistência, depois de concluída a transação, ela resultará em
um banco de dados inconsistente, que violará suas regras de integridade e de negócio.
A maioria das transações reais é formada por duas ou mais solicitações. A solicitação de
banco de dados é o equivalente a um único comando SQL em um aplicativo ou transação.
As transações podem, ainda, ser classificadas como apenas de leitura (read-only), ou seja,
quando elas apenas recuperam os dados, mas não os atualizam no banco de dados.
A seguir, vejamos alguns exemplos dos problemas mais recorrentes nas transaçõe:
1) Atualização perdida: esse problema ocorre quando duas transações são submetidas
quase ao mesmo tempo. Imagine que a Transação 1 (T1) esteja acessando os dados
do banco de dados e tenha realizado algum tipo de alteração neles. Antes que essa
alteração seja efetivada, a Transação 2 (T2) também acessou os dados e realizou uma
alteração. Nesse meio tempo, é efetivada a alteração feita por T1 e, quando T2 efetiva
sua alteração, o valor gerado pela T1 é perdido. Veja o exemplo na Figura 3:
T1 T2
ler_saldo(Saldo);
Saldo:= Saldo – X;
ler_saldo(Saldo);
escrever_saldo(Saldo);
Saldo:= Saldo + Y;
escrever_saldo(Saldo);
Figura 3 Exemplo de transação com atualização perdida.
A Figura 3 mostra que a Transação 1 leu um valor para o saldo e efetuou uma retira-
da, seguida de uma atualização. A Transação 2 leu o saldo atualizado pela Transação
1, efetuou um depósito e atualizou o saldo. Caso ocorra uma falha na Transação 1, o
valor original do saldo deve ser retornado e, temporariamente, a Transação 2 obtém
um valor incorreto para o saldo, pois ela ocorreu antes que o valor original fosse re-
tornado.

2) Sumário incorreto: esse problema ocorre quando uma transação utiliza uma função
de sumarização enquanto outras transações estão atualizando registros.
Função de sumarização é uma função que soma valores. Pode ocorrer um problema
de sumarização incorreta se essa função utilizar um valor que esteja sendo alterado
por outra função.
3) Leitura sem repetição: esse problema ocorre quando uma transação deve ler um item
duas vezes, porém, entre essas duas leituras, ocorre a modificação do item por outra
transação.
7. PROPRIEDADES DAS TRANSAÇÕES – ACID

Toda transação individual deve apresentar indivisibilidade, consistência, isolamento e du-
rabilidade. Tais propriedades constituem a sigla ACID. Quando várias transações são executadas,
o SGBD deve escalonar a execução concorrente de suas operações; para tanto, o escalonamento
deve apresentar a propriedade de ser serializável.
Vejamos, a seguir, o significado de cada uma das propriedades das transações, impostas
pelo controle de concorrência.
Indivisibilidade (ou atomicidade)

Uma transação deve ser executada por completo, ou não ser executada de forma alguma.
Esta propriedade exige que todas as operações (solicitações de SQL) de uma transação sejam
executadas por completo. A transação é abortada em caso de falha em algum dos processos que
a compõem.
Imaginemos uma transação denominada por T1, composta por quatro operações SQL, de
modo que todas devem ser concluídas com sucesso. Caso uma destas falhe, T1 deverá ser abor-
tada para garantir que nenhum dado do banco seja alterado de forma parcial ou inconsistente.
Consistência
Um banco de dados está em estado de consistência quando ele satisfaz as restrições espe-
cificadas no sistema. Esta propriedade indica a permanência do estado consistente do banco de
dados. Quando um banco de dados é consistente antes da execução de determinada transação,
ele deve continuar nesse estado de consistência após a execução completa da transação. A res-
ponsabilidade sobre a garantia dessa propriedade fica a cargo do programador, ao escrever os
programas, ou ao módulo do SGBD, responsável por garantir as restrições de integridade.
Isolamento
Essa propriedade deve garantir que a execução de uma transação não sofra interferência
das transações concorrentes. Isso significa que os dados utilizados durante a execução de uma
transação não podem ser utilizados por uma segunda transação até que a primeira seja devida-
mente concluída.
As atualizações de uma transação devem ser invisíveis às outras, até que elas sejam efeti-
vadas. Há uma classificação para os níveis de isolamento de uma transação, detalhada a seguir:
1) Isolamento de Nível 0 (não sobrescreve atualização temporária).

2) Isolamento de Nível 1 (não permite atualizações perdidas).
3) Isolamento de Nível 2 (não permite atualizações perdidas, nem atualizações tempo-

rárias).
4) Isolamento de Nível 3 (isolamento verdadeiro).
A responsabilidade pela garantia dessa propriedade é o módulo de controle de concorrên-
cia do SGBD.
Durabilidade
Essa propriedade garante que as atualizações realizadas em um banco de dados por uma
transação devem persistir no banco de dados, independentemente da ocorrência de falhas. É de
responsabilidade do módulo de restauração do SGBD.
Ser serializável
Garante que o escalonador da execução atual das transações produza resultados consis-
tentes. Essa propriedade é importante em bancos de dados distribuídos e de multiusuários, nos
quais várias transações provavelmente serão executadas de modo simultâneo. Na situação em
que apenas uma transação é/será executada por vez, a serialização se faz desnecessária.
8. FALHAS E A NECESSIDADE DE UMA RECUPERAÇÃO

Uma falha é uma condição anormal que ocorre e impede o bom funcionamento de um
sistema. Para bancos de dados, uma falha caracteriza-se quando operações de uma transação
são aplicadas enquanto outras não o são. Nesse caso, dizemos que uma transação falhou.
Elmasri e Navathe (2005) apresentam algumas razões para a ocorrência de falhas durante
a execução de uma transação, tais como:
1) Falha do computador: qualquer tipo de problema relacionado ao hardware, ao sof-
tware ou à rede.
2) Erro de transação ou sistema: são erros relacionados à lógica de programação, aos va-
lores de parâmetros ou ao overflow, o qual é ocasionado pelo estouro da capacidade
máxima de armazenamento de um buffer. Pode ocorrer, por exemplo, pelo estouro de
um número inteiro ou uma divisão por zero.
3) Erros locais ou condições de exceções detectadas pela transação: referem-se à ne-
cessidade de cancelamento de uma transação durante sua execução.
4) Imposição do controle de concorrência: relacionada às causas que fazem com que o
método de controle de concorrência aborte uma transação.
5) Falha de disco: são os problemas que podem ocorrer com o disco durante uma opera-
ção de leitura ou gravação de uma transação.
6) Problemas físicos e catástrofes: podem ser de diversas origens, tais como: falha de
energia, fogo, furto, entre outros.
Para que uma restauração seja possível, é necessário que o sistema tenha controle sobre
quando a transação inicia e finaliza, sobre suas efetivações e interrupções.
Mas qual é o procedimento para se recuperar falhas que ocorrem durante a execução das
transações?
As falhas podem ser recuperadas por meio de arquivos de log, que funcionam como uma
espécie de diário, no qual ficam registradas todas as ocorrências de controle das operações da
transação.

9. ESTADOS DE UMA TRANSAÇÃO

Na ausência de falhas, todas as transações são completadas com sucesso. Porém, quando
elas não forem executadas com sucesso (quando forem interrompidas por algum motivo ), diz-
-se que foi abortada.
Veja, a seguir, quais são os estados de uma transação, com base na realização das seguin-
tes operações:
1) begin_transaction: essa operação marca o início da execução da transação, o que
coloca a transação no chamado estado ativo.
2) read ou write: referem-se às operações de leitura ou gravação executadas por uma
transação. São operações executadas enquanto a transação se encontra no estado
ativo. Após o término da transação, ela entra no estado de efetivação parcial.
3) commit_transaction: as atualizações podem ser efetivadas no banco e não serão des-
feitas, indicando que a transação terminou com sucesso. Uma vez no estado de efeti-
vação parcial, caso seja constatado que não há falhas que impossibilitem a gravação
das mudanças efetuadas pela transação, esta passará para o estado de efetivação (é
quando dizemos que ocorre um commit).
4) rollback: esse estado realiza a operação contrária ao commit; estabelece que uma
operação não terminou com sucesso e as operações realizadas devem ser desfeitas,
ou seja, no estado de efetivação parcial constata-se que há algum tipo de falha que
impede a gravação das mudanças efetuadas pela transação. A transação entra no es-
tado de falha e é abortada. Esse estado também ocorre caso a transação seja inter-
rompida durante seu estado ativo. A operação de rollback volta o banco ao estado
original anterior à execução da transação.
5) end_transaction: marca o fim da execução de uma transação, sem nada estabelecer
sobre efetivar ou abortar as atualizações realizadas. Corresponde ao estado encerra-
do.
É desejável que as operações realizadas por uma transação estejam corretas e que sejam
efetivadas. Essa efetivação é chamada de Commit Point ou Ponto de efetivação, e só é alcançada
quando todas as operações executadas por uma transação obtiverem sucesso e seus efeitos
estiverem gravados no arquivo de log.
Quando a transação está efetivada, as operações realizadas ficam gravadas no banco de
dados de forma permanente; o mesmo ocorre com um registro de efetivação, que fica gravado
no log. Em caso de falha, são buscadas no arquivo de log as transações que ainda não tenham
gravado o seu registro de efetivação. Nessa situação, deve ocorrer um rollback, que é a reversão
das operações das transações para que os dados voltem ao seu estado original.
10. PLANOS DE EXECUÇÃO DE TRANSAÇÕES

Embora algumas transações possam ocorrer em paralelo (ao mesmo tempo), a forma mais
comum da ocorrência de transações é a estudada nesta unidade, ou seja, as transações execu-
tadas de forma concorrente e intercalada. Para controlar a ordem de execução das transações é
elaborado um plano de execução, que funciona como um histórico que define a sequência das
operações e transações.
As operações que requerem maiores cuidados no momento de restauração são as de lei-
tura, gravação, commit e rollback, uma vez que estão diretamente relacionadas com as modifi-
cações que ocorrem no banco de dados.
Um plano de execução pode estar baseado na restaurabilidade ou na serialidade.

Considera-se um plano restaurável quando nenhuma transação T for efetivada até que
todas as transações T´, que tiverem gravado um item lido por uma transação T, tenham sido
efetivadas. Esse tipo de plano permite até que algoritmos de restauração sejam elaborados se
as informações mantidas no arquivo de log forem suficientes.
Já um plano de execução baseado em serialidade é aquele em que as operações de cada
transação são executadas consecutivamente, ou seja, sem intercalar com as operações de ou-
tras transações. Um plano serial é sempre considerado correto, uma vez que uma transação,
quando executada do início ao fim, sozinha, produz um resultado final correto. O problema
desse tipo de plano, e que o torna inviável na prática, é a perda de tempo de processamento de
CPU com operações de entrada/saída, além da espera da execução completa de uma transação
para iniciar outra.
Existe, ainda, um conceito importante, que é o de conflito. Dizemos que duas operações
em um plano estão em conflito se elas pertencerem a diferentes transações, acessarem um
mesmo item do banco de dados, e pelo menos uma delas for uma operação de escrita (grava-
ção).
Desse modo, podemos dizer que um plano de execução que contém n transações é con-
siderado serializável quando ele for equivalente a algum plano serial com as mesmas n tran-
sações. E dois planos são equivalentes quando as operações aplicadas a cada item de dado
afetado por eles são aplicadas a ambos os planos.
11. TÉCNICAS DE BLOQUEIO PARA CONTROLE DE CONCORRÊNCIA

Quando as transações concorrentes estão em execução, é necessário manter um controle
sobre elas. Para isso, há técnicas como o bloqueio.
O bloqueio, também conhecido como lock, é uma variável que se associa a um item de
dados. Essa variável é responsável por descrever o que pode ser aplicado ao item em relação
às operações que são executadas pelas transações. Deve existir um bloqueio para cada item de
dado no banco de dados.
Há vários tipos de bloqueios para o controle de concorrência. Enfatizaremos, no nosso
estudo, apenas aqueles que são usados na prática e, por esse motivo, não abordaremos os blo-
queios binários.
Bloqueios compartilhados/exclusivos
Os bloqueios compartilhados/exclusivos, também conhecidos como bloqueios de leitura/
escrita, possibilitam a alteração de um item X durante uma transação, caso seu acesso seja ex-
clusivo. As operações de bloqueio e seus respectivos estados são:
• read_lock(X);
• write_lock(X);
• unlock(X).
Uma tabela de bloqueio deve ser criada para manter o controle do número de transações
que controlam um bloqueio compartilhado, cujos registros contenham as seguintes informa-
ções: nome do item de dado (que está sendo bloqueado), LOCK, número de leituras e as tran-
sações_bloqueio.

Quando o estado de lock para um determinado item for do tipo write-locked, o valor para
o atributo transações_bloqueio é uma única transação que controla o bloqueio exclusivo para
a operação de escrita. Mas se o estado de lock for do tipo read_locked, então o valor para o
atributo transações_bloqueio deve ser uma lista com uma ou mais transações que controlam o
bloqueio compartilhado para a operação de leitura.
12. REGRAS PARA O ESQUEMA DE BLOQUEIO COMPARTILHADO/EXCLUSIVO

Elmasri e Navathe (2005) apresentam algumas regras que devem ser impostas pelo siste-
ma quando é utilizado o esquema de bloqueio compartilhado/exclusivo:
1) Antes que uma transação execute qualquer operação de leitura de um item, ela deve
garantir a operação de read_lock ou write_lock do item.
2) Antes que uma transação execute uma operação de escrita de um item, ela deve ga-
rantir a operação de write_lock do item.
3) Após todas as operações de leitura e escrita de um item serem executadas por uma
transação, ela deve garantir a operação de unlock do item.
4) Se uma transação já controla um bloqueio de leitura ou de escrita de um item, ela não
gerará uma operação read_lock do item.
5) Se uma transação já controla um bloqueio de leitura ou de escrita de um item, ela não
vai gerar uma operação write_lock do item.
6) Se uma transação não controla um bloqueio de leitura ou de escrita de um item, ela
não gerará uma operação de unlock do item.
13. DEADLOCK
Deadlock refere-se à espera de uma transação por algum item que esteja bloqueado por
outra transação. É como uma fila de espera, em que cada transação fica aguardando que as ou-
tras transações do conjunto de transações libere o bloqueio de um item.
Veja o exemplo de deadlock ilustrado na Figura 4.
T1 T2
read_lock(A);
read_item(A);
read_lock(B);
read_item(B);
write_lock(B);
write-lock(A);
Figura 4 Exemplo da ocorrência de deadlock entre
duas transações.
No exemplo, temos que as duas transações T1 e T2 estão paradas, aguardando a liberação

dos bloqueios dos itens A e B. A transação T1 bloqueou o item B (lido pela transação T2) para
escrita, e a transação T2 bloqueou o item A (lido pela transação T1) para escrita. A esse impasse,
dá-se o nome de deadlock.
Um deadlock pode ser prevenido com a utilização de um protocolo de prevenção de dea-
dlock. Entretanto, como esse tipo de protocolo não é usado na prática, não abordaremos essa
técnica.
Detecção de deadlock
A detecção de deadlock é uma técnica indicada quando as transações fazem poucos aces-
sos aos mesmos itens simultaneamente. Isso acontece quando as transações são curtas e blo-
queiam poucos itens. Uma vez identificada a existência de deadlock, algumas das transações
que o causam devem ser abortadas. Há algoritmos para se fazer a escolha dessas transações.
O uso de timeouts é outra técnica para se tratar deadlock. Porém, consiste em uma técnica
mais simples, na qual o sistema define um timeout. Se a transação esperar por um tempo maior
do que o definido pelo sistema, ela entra em deadlock e é abortada.
14. TIMESTAMPS
O timestamps marca o momento do início da transação. Conforme cada transação é sub-
metida ao sistema, é gerado um valor de timestamp, que são números sequenciais.
As transações são ordenadas pelo valor de seu timestamp (algoritmo de ordenação por
timestamp). Essa ordenação pode ser de dois tipos: básica e estrita.
Veja, a seguir, as características de cada tipo de ordenação de um timestamp.
Ordenação por timestamp básica

A ordenação por timestamp básica ocorre quando uma transação tenta executar uma ope-
ração de leitura ou escrita de um determinado item. O timestamp dessa transação é comparado
aos valores das operações de leitura e escrita do item para verificar que a ordem de timestamp
da execução da transação não tenha sido violada.
Se o algoritmo de ordenação por timestamp detectar operações na ordem incorreta (con-
flito), o procedimento é abortar a transação que escolheu a última das duas operações confli-
tantes.
Ordenação por timestamp estrita

Considerada uma variação da técnica anterior, na ordenação por timestamp estrita, uma
operação de leitura ou de escrita de um item executada por uma transação é atrasada até que a
transação que escreveu o valor do item tenha sido efetivada (commit) ou abortada.
Quadro 1 Controle de Concorrência – operações de inserção e remoção em ambiente de blo-

queio e por timestamp.
CONTROLE DE CONCORRÊNCIA
Inserção Remoção
Ambiente de Definido no modo de escrita. Protocolo de escrita antes da

bloqueio Liberado com os outros bloqueios de escrita. remoção do item.
Nenhuma transação atrasada deve

Leitura e escrita têm o mesmo timestamp da
Timestamp ter lido ou escrito o item antes de
transação de criação.
sua remoção.
No Quadro 1 você pôde observar melhor as possíveis operações de inserção e remoção

em um ambiente de bloqueio e por timestamp.

15. CONTROLE DE CONCORRÊNCIA DE VALIDAÇÃO (OTIMISTA)

A técnica de controle de concorrência otimista, também conhecida por validação, não faz
verificação enquanto a transação está em execução. Ou seja, as atualizações são aplicadas às
cópias locais dos itens de dados e, ao término da execução da transação, por meio da validação,
verifica-se se alguma atualização violou a serialização. Se isso não tiver ocorrido, a transação é
efetivada e as cópias são utilizadas para a atualização do banco. Caso contrário, a transação é
abortada.

unidade:
1) A quais comandos SQL uma transação pode estar vinculada?
2) Nesta unidade, você estudou que o padrão SQL especifica que uma transação inicia de modo subentendido. Por
quais comandos uma transação pode ser finalizada? Defina tais comandos.
3) O que é uma transação? Exemplifique.
4) Quais são as propriedades de uma transação? Defina cada uma delas.
5) Quais são os principais estados de uma transação?
6) Considere um sistema bancário simplificado e a execução das transações T1 e T2 conforme o Quadro 2.
Quadro 2 Transações T1 e T2 de um sistema bancário.
Transação T1 Transação T2
1 Consulta Saldo Conta X
2 Grava Conta X com Saldo = Saldo + 100
4 Encerra T1
Se em (1) a Consulta do Saldo da Conta X resultar em 200, assinale a alternativa correta a seguir:
a) Em (3), a Consulta de Saldo resultará em 300.
b) Em (3), a Consulta de Saldo resultará em 100.
c) Em (3), a Consulta de Saldo resultará em 200.
d) Em (3), a Transação T2 entrará em espera da conclusão da Transação T1.
e) Em (5), a Consulta de Saldo resultará em 200.
7) Considere um sistema de controle de estoque de produtos simplificado e a execução das transações T1 e T2
conforme o Quadro 3.
Quadro 3 Transações T1 e T2 de um sistema de controle de estoque.
Transação T1 Transação T2
1 Soma 50 ao Estoque do Produto 1 Subtrai 10 do Estoque do Produto 4
4 Encerra T1
5 Encerra T2
Assinale a alternativa incorreta:
a) Após a execução de T1 e T2, o estoque do Produto 1 estará aumentado de 20.
b) Em (3), a Transação T2 entra em espera do encerramento de T1.
c) Ocorrerá um erro porque as duas transações alteram o estoque do Produto 1.
d) Após a execução de T1 e T2, o estoque do Produto 2 estará aumentado de 30 e o do Produto 4 diminuído
de 10.
e) A Transação T1 será executada de forma contínua, não dependendo do que ocorre na Transação T2.
8) Assinale a opção que não corresponde a uma característica de uma transação em um Sistema Gerenciador de
Banco de Dados:
a) Distributividade.
b) Atomicidade.
c) Durabilidade.
d) Consistência.
e) Isolamento.
Gabarito
6) d.
7) c.
8) a.
17. CONSIDERAÇÕES
Durante o estudo desta unidade, você teve a oportunidade de conhecer e compreender
os conceitos e as técnicas relacionados ao gerenciamento de transações e controle de concor-
rência.
Devido à complexidade e abrangência do assunto, procuramos abordar aqui os conceitos
considerados fundamentais. Recomendamos que você faça leituras com base na bibliografia
sugerida, procurando ampliar seu conhecimento, e realize as atividades propostas, pois elas o
ajudarão na fixação dos conceitos abordados.

DATE, C. J. Introdução a Sistemas de Banco de Dados. Tradução de Daniel Vieira. 8 ed. Rio de Janeiro: Elsevier, 2003.
ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados. 4. ed. São Paulo: Pearson (Addison Wesley), 2005.
SILBERSCHATZ, A. et al. Sistema de Banco de Dados. 3. ed. São Paulo: Makron Books, 1999.

Recuperação de Banco de
Dados e Segurança
1. OBJETIVOS
• Definir recuperação de dados.
• Conhecer as principais técnicas de recuperação de dados.
• Definir segurança.
• Aplicar medidas para a proteção de dados.
2. CONTEÚDOS
• Funções de um DBA.
• Backup e Recuperação.
• Caching de Disco.
• Transações: Checkpoints, Rollback.
• Recuperação baseada na Atualização Adiada.
• Recuperação baseada na Atualização Imediata.
• Paginação Shadow.
• Recuperação de falhas em Bancos de Dados Múltiplos.
• Recuperação de falhas por motivos de catástrofe.
• Segurança de Dados.
• Medidas de proteção aos Bancos de Dados.
232

guir:
1) Nesta unidade, serão apresentadas as técnicas mais importantes de recuperação de
dados. Reflita sobre os problemas que podem acontecer no dia a dia de uma empresa
e que possam afetar os dados de seu banco. Recorra à bibliografia indicada para apro-
fundar seus conhecimentos.
2) Essa unidade é considerada por muitos DBAs (Administradores de Banco de Dados)
a mais importante, pois, ao seu término, você poderá definir planos de recuperação
de dados, conhecer e compreender adequadamente as principais técnicas de recupe-
ração de dados, definir regras de acesso aos dados no banco de dados (segurança) e
protegê-los por meio, por exemplo, do uso de criptografia (PostgreSQL – MD5 "Mes-
sage-Digest algorithm 5").
3) Fique atento a todo o conteúdo, especialmente, às técnicas de recuperação de dados
(caching, checkpoints, rollback, shadow, backup).
4) Verifique quais são os principais mecanismos de contingência que promovem o aces-
so aos dados 24x7 (24 horas por dias, 7 dias por semana).
Ao final, você certamente implementará, em seus novos projetos, medidas para a pro-
teção de dados, por exemplo: a implementação da criptografia em senhas, números
de cartão de crédito, CPF, entre outros.
Na unidade anterior, estudamos que as informações sobre as atualizações que são reali-
zadas no banco de dados, pelas transações, ficam armazenadas no arquivo de log do sistema.
Nesta unidade, veremos que, em banco de dados, recuperação significa restauração. Essa
operação ocorre quando as transações falham e o banco precisa ser restaurado. Tais operações
devem ser controladas e executadas por um Administrador de Banco de Dados (DBA).
5. FUNÇÕES DE UM DBA
As responsabilidades do DBA variam a cada organização, mas, de modo geral, o DBA deve-
rá planejar a estratégia de administração de dados. São funções do DBA definir, implementar e
aplicar as políticas, padrões e procedimentos pertinentes a uma melhor conduta para o zelo das
informações contidas em um banco de dados.
Algumas operações envolvidas no trabalho do DBA, dentre as fases que constituem o pro-
jeto do banco de dados, são:
1) Planejamento do banco de dados: definição de padrões e procedimentos.
2) Coleta das necessidades de banco de dados e projeto conceitual.
3) Projeto lógico e transacional do banco de dados.
4) Projeto físico e implementação do banco de dados.
5) Teste e depuração do banco de dados.
6) Operações de manutenção do banco de dados, incluindo instalação, conversão e mi-
gração.
Veja, na Figura 1, a organização funcional do DBA.
© U7 - Recuperação de Banco de Dados e Segurança 233
Figura 1 Organização funcional do DBA.
O DBA tem importante papel técnico e exige uma ampla compreensão das funções, da
configuração, das linguagens de programação, da modelagem de dados, das metodologias de
projeto e do SGBD como um todo. Atividades como segurança, integridade, backup e recupera-
ção, treinamento e suporte são tarefas que serão recorrentemente vivenciadas dentro do cam-
po de trabalho de um DBA.
6. BACKUP E RECUPERAÇÃO
Um dos maiores ativos das organizações é o seu contingente informacional, e quando uma
organização necessita acessar determinada informação que não está prontamente disponível,
perdas podem ser geradas. Por isso, procedimentos de backup e restauração são imprescindí-
veis para assegurar a proteção e a constante disponibilidade das informações obtidas e acumu-
ladas ao longo do tempo.
Os procedimentos de backup e restauração são importantes em qualquer SGBD utilizado.
O DBA em questão deve garantir que os dados possam ser recuperados totalmente em caso de
perda física ou de perda de integridade dos dados.
A perda de dados pode apresentar-se de forma total ou parcial. A parcial ocorre em função
da perda de parte do banco de dados, especialmente de integridade. Já na perda total, o banco
de dados pode continuar a existir, mas a integridade ou o banco de dados físico é totalmente
perdido. Devido à série de problemas e "ameaças" que inferem no bom funcionamento e na dis-
ponibilidade correta dos dados, o DBA deve ater-se aos procedimentos de backup e restauração.
As atividades do DBA incluem o gerenciamento de desastres, de modo a garantir a dispo-
nibilidade dos dados após um possível desastre, seja ele físico ou uma falha de integridade. Para
tanto, é necessário um planejamento sistêmico dentro da organização, que deverá compreen-
der: planos de testes e planejamento de ações e procedimentos necessários à recuperação.
A seguir, observe as medidas que devem ser adotadas para os procedimentos de backup
e restauração dos dados.
1) Backups periódicos de dados e aplicações: muitos dos SGBDs utilizados atualmente
dispõem de ferramentas que garantem o backup e a recuperação dos dados no ban-
co. Cabe ao DBA fazer uso dessas ferramentas, de modo a adotar automatismo a tais
procedimentos. Em termos de banco de dados, denomina-se de dump o backup com-
pleto.

234
2) Identificação adequada dos backups: os backups, ou arquivos de dump, devem ser

devidamente identificados, de forma detalhada (especialmente quanto à data) para
facilitar a sua utilização por meio do DBA, caso necessário.
3) Armazenamento de backup: deve ser feito de modo conveniente e seguro. Possivel-
mente, no decorrer do tempo, muitas cópias de pontos distintos do banco de dados
deverão acumular-se; assim, cada cópia deve ser armazenada em um local diferente.
É importante ressaltar que os locais para abrigo das cópias devem dispor de pontos
internos e externos da organização. As localizações de armazenamento devem estar
adequadamente preparadas e podem incluir recintos à prova de incêndio e terremo-
to, bem como controle de umidade e temperatura.
4) Proteção física de hardware e software: a proteção dos dados vai muito além de po-
líticas de acesso em nível de aplicação e precisa ser controlada de modo físico. Logo,
deve-se considerar o uso de instalações fechadas e com acesso restrito, além de dis-
por da infraestrutura adequada ao abrigo dos dados. A proteção física também inclui
a obtenção de um computador reserva e de um SGBD a ser utilizado em caso de emer-
gência.
Lembre-se de que o maior bem de uma empresa é a informação que ela guarda e que
permite a tomada de decisão por parte de seus gestores. Portanto, cuidar da informação é ga-
rantir que as decisões tomadas com base nela utilizem dados íntegros e, consequentemente,
confiáveis.
7. CACHING DE DISCO
Caching de disco, também conhecida como bufferização, é uma técnica na qual os itens
de dados a serem atualizados podem ficar armazenados nos buffers da memória principal para
serem atualizados e, somente depois, gravados no disco. O SGBD mantém controle sobre esses
buffers.
Os itens do banco de dados que ficam nos buffers são anotados em um catálogo. Dessa
forma, quando o SGBD solicitar algum item, primeiro será verificado se o item se encontra no
catálogo. Cada buffer no cache recebe um valor para um determinado atributo, para indicar se
houve ou não alteração do seu conteúdo. Quando a página é lida pela primeira vez, o atributo
recebe o valor zero (0). Sempre que houver uma atualização e o buffer for modificado, o valor
do atributo passa para um (1).
8. TRANSAÇÕES: CHECKPOINTS, ROLLBACK

Na unidade anterior, discutimos o uso de transações e sua importância para a manute-
nibilidade da consistência e da integridade dos dados. Neste tópico, estudaremos como uma
transação pode ser usada como fator de recuperação dos dados.
Sabe-se que uma transação começa com a execução bem-sucedida de uma instrução be-
gin transaction e termina com a execução bem-sucedida de uma instrução commit ou de uma
instrução rollback. Um commit pode ser entendido também, entre muitas outras coisas, como
um ponto de commit ou validação, que corresponde ao fim de uma unidade lógica de trabalho
(transação) e, em consequência, a um ponto no qual o banco de dados está, ou deveria estar,
em um estado consistente. Em contraponto ao commit, o rollback devolve o banco de dados
ao estado em que ele se encontrava em begin transaction. Isso significa o retorno ao ponto de
commit anterior.
Quando um ponto de commit é estabelecido, temos que:

• Todas as instruções e operações SQLs compreendidas desde o ponto de commit ante-
rior são validadas, ou seja, são realizadas as alterações no banco. Todo comando ante-
rior descrito ao operador commit deve ser considerado como tentativas, pois podem
ser desfeitos de acordo com o resultado apresentado.
• Todos os bloqueios de tuplas realizados no início da transação serão liberados.
Observe que os comandos de commit e rollback determinam o término de uma transação.
Um checkpoint é um tipo de entrada no log. Ele acontece quando o sistema grava no ban-
co de dados (no disco) os buffers que sofreram alterações.
Neste momento, não nos deteremos nesse conceito, pois ele foi discutido na unidade
anterior. Caso ainda tenha alguma dúvida a respeito, retome o conteúdo da Unidade 6 ou entre
em contato com o seu tutor.
9. RECUPERAÇÃO BASEADA NA ATUALIZAÇÃO ADIADA

Como o próprio nome diz, as técnicas de recuperação baseadas na atualização adiada
desprezam a atualização dos dados no banco de dados até que a transação seja efetivada. Uma
vantagem desse tipo de técnica é que, caso a transação não se efetive, não há necessidade de
desfazer qualquer operação, uma vez que não houve alteração dos dados no banco.
As técnicas de atualização adiada especificam que:
• Uma transação não altera o banco de dados até que ela se efetive.
• Para alcançar seu ponto de efetivação, é necessário que todas as operações de atuali-
zação da transação sejam registradas no log.
As técnicas de recuperação baseadas na atualização adiada podem ser utilizadas em am-
bientes monousuário e multiusuário.
Há, ainda, as transações que não afetam o banco de dados. É o caso de operações que
geram relatórios, por exemplo. Havendo falha na transação, as informações que constituiriam os
relatórios podem não ser consistentes. Nesses casos, uma medida a ser tomada é a criação de
tarefas em lote, as quais serão executadas somente depois que a transação for efetivada.
10. RECUPERAÇÃO BASEADA NA ATUALIZAÇÃO IMEDIATA

A técnica de recuperação baseada na atualização imediata atualiza o banco de dados tão
logo uma operação de atualização seja iniciada pela transação, sem aguardar a sua efetivação.
Há dois tipos de algoritmos baseados na atualização imediata. Veja:
1) O algoritmo de recuperação undo/no-redo, que será empregado quando as técnicas
de recuperação garantirem que as atualizações de uma transação serão registradas
no banco de dados antes que a transação se efetive. O termo no (no-redo) significa
que, nesse caso, nunca haverá necessidade de refazer as operações das transações
efetivadas.
2) O algoritmo o undo/redo: nesse caso, se a transação se efetivar antes que as atualiza-
ções sejam escritas no banco de dados, haverá necessidade de recuperação.

236
11. PAGINAÇÃO SHADOW

Podemos pensar na paginação shadow (sombra) como dois catálogos, de forma que cada
entrada de um catálogo sempre aponta para a página do banco de dados em disco correspon-
dente a essa entrada. Todas as vezes que uma transação tiver início no catálogo corrente, o con-
teúdo desse catálogo é copiado para um catálogo shadow. Este nunca é modificado e também
fica gravado em disco.
Se uma operação de escrita é realizada, a cópia antiga dessa página não será sobrescrita,
embora a nova página seja gravada em outro lugar. O catálogo corrente passa a apontar para o
novo bloco de disco, enquanto o shadow continua a apontar para o bloco de disco antigo. Dessa
forma, o estado do banco de dados antes da execução da transação se encontra no catálogo
shadow e, em caso de falha, basta descartar o catálogo corrente, no qual estão as modificações
gravadas das operações de atualização.
Essa técnica apresenta como desvantagem a dificuldade em manter juntas as páginas re-
lacionadas, uma vez que elas mudam de localização no disco, além do tempo gasto pelo sistema
operacional (overhead) para a gravação do catálogo shadow quando as transações são efetiva-
das.
12. RECUPERAÇÃO DE FALHAS EM BANCOS DE DADOS MÚLTIPLOS

Quando trabalhamos com mais de um banco de dados, as dificuldades na recuperação de
falhas são maiores, pois o acesso é realizado a diversos bancos, que podem estar armazenados
em SGBDs diferentes (relacionais, orientados a objetos etc.) e usar diferentes técnicas de recu-
peração.
Nesses casos, a atomicidade de uma transação é garantida por meio de um mecanismo de
recuperação em dois níveis. Observe:
1) No primeiro nível, há uma coordenação das tarefas para que possa ocorrer a efeti-
vação da transação. Nessa coordenação, todos os bancos participantes se preparam
para concluir a efetivação.
2) No segundo nível, ou o coordenador de tarefas recebe um ok de todos os participan-
tes como sinal de sucesso na tarefa de efetivação da transação, indicando que ela foi
bem-sucedida, ou significa que houve falha na transação.
Veja que as informações para a recuperação dos dados ficam registradas nos logs dos ban-
cos de dados de cada participante. O protocolo para esse tipo de recuperação estabelece que
todos os participantes efetivem a transação, ou que ninguém o faça. E, ainda, caso haja falha, é
possível recuperar o estado anterior dos dados do banco de dados.
13. RECUPERAÇÃO DE FALHAS POR MOTIVOS DE CATÁSTROFE

As técnicas de recuperação de dados anteriormente estudadas nesta unidade tratam da
recuperação de falhas por problemas na efetivação das transações e são baseadas em informa-
ções geradas nos arquivos de log dos sistemas envolvidos. Dessa forma, é possível retornar o
estado do banco de dados ao estado anterior à realização da atualização, mantendo a consis-
tência dos dados.
Contudo, problemas classificados como falhas catastróficas podem ocorrer, e a técnica de
recuperação utilizada é a de backup dos dados. Esse é um procedimento bastante comum e apli-
cado aos bancos de dados como forma de manter a atualização e a segurança das informações
contidas no banco de dados.
O backup consiste em copiar os dados gravados no disco magnético, assim como o arquivo
de log, em uma mídia mais barata e removível, ou mesmo em um disco de outro computador.
14. SEGURANÇA DE DADOS

O conceito de segurança está diretamente relacionado à proteção de valores e, no caso
de bancos de dados, à proteção das informações contidas no banco. É valido mencionar que a
segurança dos dados não deve ser apenas em relação ao sistema, mas exige uma postura em
prol da segurança em toda a empresa.
Segurança significa garantir que os usuários terão permissão de fazer aquilo que estão
tentando fazer, e integridade envolve a certeza de que aquilo que eles estão tentando fazer está
correto. Muitos são os aspectos a serem considerados na temática de segurança, dentre eles:
1) Aspectos legais, sociais e éticos: por exemplo, qualquer pessoa poderia solicitar o
saldo bancário ou a remuneração de outra pessoa ?
2) Controles físicos: acesso físico no ambiente da empresa, por exemplo, a sala onde se
encontra o servidor de banco de dados possui controle de entrada de pessoas? Quem
pode entrar nessa sala? O DBA? A faxineira?
3) Questões de normas: estabelecer os privilégios de acesso de cada indivíduo da em-
presa, por exemplo.
4) Problemas operacionais: como as senhas individuais são zeladas, e a periodicidade
que são alteradas, por exemplo.
Três atributos são considerados quando se trata de segurança: integridade, disponibilida-
de e confidencialidade. Quando os dados de um banco de dados estão sob ameaça, são esses
os atributos que refletem o quanto a segurança pode estar sendo afetada. Vejamos a sua im-
portância:
1) Integridade: dentro do modelo de segurança de dados, este conceito refere-se à ma-
nutenção da consistência e da ausência de erros ou ações não procedentes. A inte-
gridade está focada na manutenção dos dados livres de inconsistência, não só em
relação ao banco de dados, mas também como garantia de que os processos, usuários
e padrões de utilização das organizações permaneçam íntegros.
2) Disponibilidade: refere-se à possibilidade de acesso aos dados por usuários autori-
zados para finalidades específicas sempre que solicitado. Para assegurar a disponi-
bilidade dos dados, todo o sistema deve estar protegido contra a degradação ou a
interrupção de serviço causada por qualquer fonte.
3) Confidencialidade: garante que os dados estejam protegidos contra o acesso não
autorizado e, em caso de acesso autorizado, que sejam utilizados apenas para a fi-
nalidade designada. Portanto, a confidencialidade deve ser entendida como fator de
proteção aos dados contra a divulgação de qualquer informação que viole os direitos
de privacidade de uma pessoa ou uma organização. Os dados devem ser avaliados
e classificados de acordo com o nível de confidencialidade: altamente confidenciais,
confidenciais e não confidenciais.
Vale ressaltar que violar qualquer um desses atributos pode levar ao uso de dados cor-
rompidos, o que causaria imprecisão e tomadas de decisão com base em dados irreais, perda da
confiança, constrangimentos, entre outros problemas relacionados.
Veremos, mais adiante, as medidas que devem ser tomadas para proteger os dados. São
elas: o controle de acesso, o controle de inferência, o controle de fluxo e a criptografia. Mas,
238
antes, vejamos os dois mecanismos de segurança de banco de dados: os mecanismos de acesso

discricionário e os mecanismos de acesso obrigatório, explicados a seguir.
Mecanismos de acesso discricionário

No controle de um sistema de banco de dados, mecanismos de acesso discricionário são
aqueles utilizados na concessão e na revogação de privilégios a usuários.
Para exemplificar, imagine um banco de dados de uma empresa. Nele, todas as pessoas
com acesso aos dados podem acessar todos os dados disponíveis no banco. Há pessoas traba-
lhando na empresa com diferentes interesses nos dados e nas informações contidas.
É por isso que o DBA precisa, no momento da criação da conta de cada usuário, definir o
nível de permissão de acesso aos dados.
Além disso, pode haver casos em que os dados armazenados no banco são extremamente
confidenciais, devendo ser acessados apenas por pessoas rigorosamente escolhidas para isso.
Ou, ainda, há dados que podem ser alterados, e essa operação somente será realizada por pes-
soas autorizadas e que poderão responder por esse tipo de ação, caso necessário.
Dessa forma, ao criar uma conta, o DBA pode estabelecer dois níveis de privilégios. Veja
a seguir:
1) O nível de conta: em que são estabelecidos os privilégios para cada conta, tais como a
capacidade para criar, excluir e alterar esquemas, relações, atributos, fazer consultas,
entre outros.
2) O nível de relação: no qual é controlado, pelo DBA, o privilégio para o acesso das rela-
ções. Nesse nível, para cada relação em um banco de dados é atribuída uma conta de
proprietário, o qual recebe todos os privilégios sobre aquela relação.
Faz-se necessária a existência de uma linguagem que admita a definição de restrições de
segurança (discricionárias). Porém, por diversas razões, é mais fácil declarar o que é permitido
do que enunciar o que não é permitido. Portanto, as linguagens, em geral, admitem a definição,
não de restrições de segurança em si, mas de autoridades – que são efetivamente o oposto das
restrições de segurança (se algo é autorizado, não é restringido).
Observe, a seguir, um exemplo da sintaxe da linguagem que definirá uma autorização:
AUTHORITY AUT_EXEMPLO
GRANT RETRIEVE ( F#. FNOME. CIDADE ), DELETE
ON FUNCIONARIO F
TO Joao, Maria, Pedro ;
Notamos no exemplo anterior o uso de quatro componentes para a aplicação de uma

autorização. São eles:
1) Nome: nome que será atribuído à autorização. No exemplo ilustrado, o nome definido
é AUT_EXEMPLO.
2) Privilégios: tipo de privilégio que está sendo concedido. Conforme o exemplo, obser-
va-se a atribuição de permissão para seleção de apenas alguns atributos da tabela
FUNCIONARIO e a permissão para deleção dos registros.
3) Variável de Relação: esta variável é especificada na cláusula ON e ilustrada por F no
exemplo.
4) Usuários: por fim, os usuários que estão recebendo a autorização.
Tem-se que a sintaxe geral para atribuição de autorizações é dada por:
AUTHORITY <nome de autoridade>
GRANT <lista_com_vírgulas de privilégios>
ON <nome de variável de relação>
TO <lista_com_vírgulas de IDs de usuários>
Em um dado momento, pode ser necessário que a autorização concedida seja anulada, e
talvez excluída. Observe no exemplo a seguir:
DROP AUTHORITY <nome de autoridade>
Os privilégios, nesse caso, são:

1) Privilégio SELECT (recuperação ou leitura): refere-se ao privilégio de recuperar tuplas
da relação em questão.
2) Privilégio MODIFY: refere-se aos privilégios que permitem a modificação das tuplas da
relação por meio de comandos como UPDATE, DELETE e INSERT.
3) Privilégio REFERENCES: refere-se ao privilégio de se referenciar uma relação quando
ela especificar restrições de integridade.
4) A revogação de privilégios refere-se ao cancelamento dos privilégios.
Mecanismos de acesso obrigatório

Mecanismos de acesso obrigatório são aqueles utilizados para impor segurança por meio
de uma política de segurança. Os usuários e os dados são classificados em classes ou em níveis
de segurança.
Quanto aos bancos de dados relacionais, os mecanismos de acesso discricionário são os
mais utilizados. Há, porém, determinados tipos de aplicações que necessitam de segurança em
nível e, nesses casos, são utilizados os mecanismos de acesso obrigatório.
Os níveis ou classes de segurança são divididos em:
1) Altamente secretas.
2) Secretas.
3) Confidenciais.
4) Não confidenciais.
Mecanismos de Acesso Discricionário versus Mecanismos de Acesso Obrigatório

Os mecanismos de acesso discricionário e os mecanismos de acesso obrigatório não são
muito utilizados e, por essa razão, não nos aprofundaremos nesse assunto.
Observe, no Quadro 1, uma comparação entre os dois tipos de mecanismos.
Quadro 1 Mecanismos de Acesso Discricionário versus Mecanismos de Acesso Obrigatório.

ACESSO DISCRICIONÁRIO ACESSO OBRIGATÓRIO
Vantagens Políticas de alto grau de flexibilidade. Políticas de alto grau de proteção.
Vulnerabilidade a ataques
Desvantagens Políticas muito rígidas.
maliciosos.
Ao analisarmos o Quadro 1, podemos perceber que as políticas de acesso discricionário

têm como desvantagem a vulnerabilidade a ataques porque, embora os acessos sejam realiza-
dos por pessoas autorizadas, não há controle sobre como os dados são usados ou propagados.

240
Ao contrário, as políticas de acesso obrigatório oferecem alto grau de proteção, pois, uma vez
impostas, evitam o fluxo ilegal dos dados e, por essa razão, são adequadas ao uso de órgãos
governamentais e militares, que exigem alto grau de proteção aos dados acessados.
15. MEDIDAS DE PROTEÇÃO AOS BANCOS DE DADOS

Neste tópico, abordaremos detalhadamente as medidas que devem ser tomadas para pro-
teger os dados: o controle de acesso, o controle de inferência, o controle de fluxo e a criptogra-
fia.
Controle de acesso
Conhecido por DBA, o Administrador do Banco de Dados é o responsável por gerenciar
o sistema de banco de dados, o que inclui a responsabilidade pela segurança das informações
contidas no banco.
O Administrador do Banco de Dados pode criar contas para os usuários, conceder e re-
vogar privilégios e atribuir o nível de segurança adequado a cada tipo de usuário do banco de
dados. Para cada novo usuário, o DBA cria uma conta e uma senha. Ao entrar no sistema (login),
o SGBD valida a conta e a senha para disponibilizar os dados aos quais o usuário tem direito de
acesso.
Depois que o usuário já está devidamente autorizado a trabalhar com os dados, todos
os procedimentos executados por ele durante sua sessão de login são mantidos. A partir do
momento da conexão, sua conta fica registrada pelo SGBD, assim como o terminal ao qual se
conectou. Dessa forma, todas as operações executadas por um determinado usuário ficam re-
gistradas. Caso haja qualquer problema com o banco de dados, é possível descobrir qual foi o
responsável por causá-lo.
O registro das operações realizadas pelo usuário fica nos mesmos arquivos de log. Se hou-
ver necessidade, pode ser realizada uma auditoria de banco de dados, ou seja, uma verificação
nos arquivos de log para a identificação dos usuários e as operações realizadas por eles.
Controle de inferência
O controle de inferência refere-se à segurança de bancos de dados estatísticos e assegura
que os dados estatísticos serão acessados somente por pessoas autorizadas (gerentes, adminis-
tradores, diretores), pois a maioria desses dados estatísticos é utilizada para criar o ambiente de
BI (Business Intelligence), auxiliando a tomada de decisões empresariais)
Portanto, os bancos de dados estatísticos devem fornecer aos usuários os dados sobre os
indivíduos que compõem a população analisada, porém, devem assegurar a sua confidenciali-
dade.
Um problema que pode ocorrer é o da inferência a partir de consultas. Isso significa que
uma determinada informação pode não estar explícita no banco, mas pode ser "deduzida" a
partir da realização de várias consultas que levem o usuário a ter uma compreensão sobre as
informações obtidas, inferindo em um resultado. Isso pode ocasionar também em resultados
das consultas com valores que levem a uma inferência com alguma margem de erro. Por isso,
uma medida de segurança é a de não permitir consultas estatísticas quando o número de linhas/
tuplas de um determinado conjunto de informações ficar abaixo de um limiar considerado sa-
tisfatório pelos gerentes.
Controle de fluxo
O controle de fluxo é o responsável pela distribuição das informações entre os usuários
que têm permissão de acesso a elas e também por verificar se os usuários que recebem as infor-
mações têm permissão para recebê-las.
Você se lembra das classes de segurança apresentadas no Tópico Mecanismos de Acesso
Obrigatório? Pois bem, os controles de fluxo empregam o conceito de classes de segurança, o
que significa que, quando uma informação é enviada de um emissor a um receptor, a classe de
segurança do receptor deve ter, no mínimo, o mesmo privilégio que o da classe do emissor.
Quem determina por onde a informação deve caminhar é a política de fluxo. Por exemplo,
se as informações pertencerem às classes Confidencial e Não Confidencial, somente não será
permitido o fluxo de uma informação da classe Confidencial para a classe Não Confidencial.
Criptografia
A criptografia é um método que consiste em cifrar dados, de forma que eles fiquem dis-
farçados e não possam ser compreendidos (caso sejam acessados por algum tipo de usuário
sem permissão), além de manter os dados seguros em um ambiente não provido de segurança
satisfatória.
O processo consiste na aplicação de um algoritmo de criptografia, com o uso de uma cha-
ve de criptografia. Depois, para voltar os dados ao estado original, eles são decifrados por meio
de uma chave de criptografia. Quando uma mensagem criptografada é enviada a um destinatá-
rio, somente ele possui a chamada chave secreta, com a qual poderá ler a mensagem.
O governo dos Estados Unidos desenvolveu um sistema – Padrão de Criptografia de Da-
dos – que tem sido bastante aceito como padrão de criptografia. Trata-se de um algoritmo que
combina substituição e permutação, duas técnicas utilizadas na construção de criptografia.
Mensagens do tipo texto são cifradas em blocos de 64 bits (tamanho da chave), embora já exis-
tam outros padrões mais avançados, que trabalham com blocos de 128 bits.
A assinatura digital é uma cadeia de símbolos que utiliza técnicas de criptografia. Ela deve
associar um símbolo a uma pessoa, em um texto, de forma que esse símbolo permita que outras
pessoas identifiquem o dono da assinatura.
Entretanto, a assinatura digital não pode ser sempre a mesma para cada texto em que
ela aparece, pois seria alvo fácil de falsificação. Para que uma assinatura digital seja à prova de
falsificação, ela depende da mensagem e de um número secreto, que é único para o assinante.
Isso significa que a assinatura digital será criada com base em cada nova mensagem, além de um
registro da data e da hora, que reforçam a sua segurança.

unidade:
1) Quais são as operações funcionais de um DBA?
2) Qual é a finalidade dos procedimentos de backup e restauração?
3) Quais são as medidas que devem ser adotadas para os procedimentos de backup e restauração dos dados den-
tro de uma organização?

242
4) Explique a recuperação baseada na atualização adiada e recuperação baseada na atualização imediata.
5) Que tipos de problema um DBA pode enfrentar quando trabalha com recuperação de falhas em bancos de
dados múltiplos?
6) Basicamente, três atributos devem ser considerados quando se trata de segurança. Defina-os detalhadamente.
7) Qual é o algoritmo usado para implementar a criptografia no PostgreSQL? Dê um exemplo, criptografando a

frase Banco de Dados.
17. CONSIDERAÇÕES
Nesta unidade, você teve a oportunidade de conhecer algumas técnicas de recuperação
de dados em banco de dados, em casos de ocorrência de falhas, e também estudou conceitos
relacionados à segurança dos dados – ambos de extrema importância para o sistema de bancos
de dados.
A recuperação refere-se a retornar os dados ao seu estado original no banco de dados,
caso uma transação falhe. Pode, também, estar relacionada a problemas físicos com o meio de
armazenamento: um problema no disco em que os dados estiverem gravados, por exemplo.
A questão da segurança trata de manter a integridade e a confidencialidade de informa-
ções. Há diferentes técnicas que são aplicadas de acordo com a necessidade de segurança para
as informações a serem acessadas.
Depois do estudo desta unidade, você consegue pensar nas consequências das falhas na
segurança dos dados de uma empresa? Tente relacioná-las às formas de manter a segurança
dos dados, a fim de se evitar prejuízos. Reflita a respeito e compartilhe suas reflexões com seus
colegas de turma.

DATE, C. J. Introdução a Sistemas de Banco de Dados. 8. ed. Tradução de Daniel Vieira. Rio de Janeiro: Elsevier, 2003.
ROB, P.; CORONEL, C. Sistemas de Banco de Dados – projeto, implementação e administração. São Paulo: Cengage Learning,
2011.
Banco de Dados Distribuídos
1. OBJETIVOS
• Definir Fragmentação de Dados e reconhecer os tipos de Fragmentação.
• Explicar Replicação e Alocação de Dados.
• Classificar Sistemas Gerenciadores de Banco de Dados Distribuídos (SGBDDs).
• Conceituar Transação Distribuída.
• Identificar as falhas que ocorrem em Bancos de Dados Distribuídos.
2. CONTEÚDOS
• Fragmentação de Dados e seus tipos.
• Replicação e Alocação de Dados.
• Consultas em Bancos de Dados Distribuídos.
• Transação Distribuída.
• Controle de Concorrência e de Recuperação.

guir:
1) Daremos início ao estudo da penúltima unidade. Pare e pense se você compreendeu
o conteúdo estudado até agora. Caso tenha dúvidas, ainda é tempo de saná-las: entre
em contato com seus colegas de turma e seu tutor.
2) Lembre-se de que o Apêndice 2 aborda as operações da Álgebra Relacional. Em caso

de dúvidas, consulte seu tutor.
3) Já estamos esgotando os conteúdos. Essa unidade discorre sobre Banco de Dados Dis-
tribuídos, tema extremamente importante no cenário atual, principalmente se consi-
derarmos o surgimento recente da Big Data.
4) Considere a importância de definirmos corretamente a replicação dos dados distribu-
ídos pelos diversos nós (sites), os quais estão conectados por alguma rede de comuni-
cação, seja ela convencional ou de alto desempenho.
5) Atente-se aos diversos mecanismos de fragmentação de dados (horizontal, vertical e
mista), abstraindo seus objetivos e usabilidade.
6) Você perceberá a complexidade de conceituar e colocar em prática (implementar)
transações distribuídas. Identificar qual nó (site) receberá todos os fragmentos dos
demais bancos de dados distribuídos facilitará a continuidade do banco de dados em
caso de falhas oriundas dos bancos de dados distribuídos.
7) Para mais informações sobre o protocolo commit de duas fases, sugerimos que você
consulte as obras indicadas nas referências bibliográficas.
Na unidade anterior, você teve a possibilidade de aprender como recuperar dados em
bancos de dados e conhecer as principais técnicas de recuperação, a segurança de dados e algu-
mas medidas que podem ser tomadas para garantir a segurança dos dados.
Nesta unidade, estudaremos os Bancos de Dados Distribuídos. Existe um conceito que
define a computação distribuída e que pode ser aplicado não somente a banco de dados, mas a
quaisquer componentes que se encontram em computadores ou em locais diferentes e que, de
alguma forma, se relacionam. Observe:
Um sistema de computação distribuída pode ser entendido como vários componentes li-
gados por uma rede de computadores e que se relacionam para executarem tarefas em comum.
Segundo Elmasri e Navathe (2005, p. 579), Banco de Dados Distribuído (BDD) pode ser
definido como "uma coleção de múltiplos bancos de dados logicamente inter-relacionados, dis-
tribuídos por uma rede de computadores".
Um Sistema de Gerenciamento de Banco de Dados Distribuídos (SGBDD) tem por finalida-
de controlar o armazenamento e o processamento de dados relacionados logicamente por meio
de sistemas computacionais interconectados. Neste contexto, tanto os dados como as funções
de processamento são distribuídos entre os diversos locais, ou seja, uma matriz e inúmeras
filiais.
Ao analisar este novo modelo de banco de dados, o SGBDD enuncia que uma única apli-
cação deve possuir meios para que gerencie/opere de forma transparente, ou seja, sem que o
usuário tenha que fazer definições específicas em conformidade com sua necessidade, dados
dispersos. Podemos entender dispersão de dados como sendo um sistema de distintos SGBDs,
em servidores não centralizados, com sistemas operacionais não necessariamente iguais, em
outras palavras, um ambiente heterogêneo de dados.
A operação dos dados de forma transparente significa que, para o usuário que faz uso dos
dados por meio de uma aplicação qualquer, todo acesso deverá ocorrer de modo imperceptível,
para que tal distribuição não afete em nada sua usabilidade.
© U8 -Banco de Dados Distribuídos 245
O surgimento desta nova arquitetura de banco de dados veio atender a nova demanda de
corporações, que têm sofrido grandes mudanças em seus paradigmas administrativos, especial-
mente quanto à incorporação de meios tecnológicos.
Os primeiros sistemas de banco de dados foram implantados em meados da década de
1970, para atender as necessidades de armazenamento de informações de forma estruturada.
Esta centralização exigia que os dados corporativos fossem armazenados em um único local cen-
tral, normalmente um main-frame. Todo o acesso era provido em terminais sem capacidade de
processamento, os quais realizavam apenas consultas/solicitações aos main-frames.
Veja, na Figura 1, a abordagem de centralização dos dados.
Figura 1 Sistemas de Gerenciamento de Banco de Dados Centralizado.
O modelo centralizado funcionava adequadamente para atender as necessidades de in-

formações estruturadas das corporações, mas era insuficiente quando eventos que exigiam mu-
danças rápidas demandavam um menor tempo resposta para acesso às informações.
Já os Sistemas de Gerenciamento de Banco de Dados que tinham suas bases no modelo
relacional eram capazes de oferecer o ambiente para o atendimento de necessidades de infor-
mações não estruturadas.
As mudanças impostas pelo advento tecnológico às organizações impactaram não apenas
nos processos administrativos, mas também inferiram no modo como o projeto de banco de
dados é desenvolvido. Dentre as principais mudanças, elencam-se:
1) As operações comerciais tornaram-se descentralizadas.
2) A competição é mais acirrada em nível global.
3) As demandas dos clientes e as necessidades de mercado favoreceram um estilo de
gerenciamento descentralizado.
4) A rápida mudança tecnológica criou computadores de baixo custo com capacidades
semelhantes às dos main-frames até então utilizados.
5) O grande número de aplicações baseadas em SBGDs e a necessidade de proteger in-
vestimentos em software de SGBDs centralizados tornaram atraente a ideia de com-
partilhamento de dados. Tem-se observado, também, que aplicações únicas geren-
ciam diferentes tipos de dados (voz, vídeo, música, imagens, entre outras), que podem
ser acessados a partir de diferentes localizações dispersas geograficamente.
Essas mudanças propiciaram a criação de um ambiente comercial dinâmico, no qual as
empresas tinham de responder rapidamente a pressões competitivas e tecnológicas. Certamen-
te, os meios que mais influenciaram tais mudanças foram baseados na crescente adoção da

internet como plataforma de acesso e distribuição de dados; na revolução das redes sem fios
pela qual o uso de dispositivos móveis tem se tornado cada vez mais comum (todos esses dispo-
sitivos acessam os dados a partir de localizações geograficamente variadas); no crescimento de
empresas que fornecem serviços de aplicações; na maior valorização dos dados (no sentido de
aplicar formas de análise e manipulação).
Esse cenário inovador e de mudanças contínuas tem feito com que os bancos de dados
descentralizados tornem-se mais adequados ao atendimento das novas demandas, haja vista
que os atuais Sistemas de Gerenciamento de Bancos de Dados Centralizados estão sujeitos a
alguns fatores como:
1) Queda de desempenho em razão do número crescente de localizações remotas.
2) Altos custos associados à manutenção e operação de grandes sistemas centrais.
3) Problemas de confiabilidade criados pela dependência de um local central.
4) Problemas de escalabilidade associados aos limites físicos impostos por uma única
localização.
5) Rigidez organizacional imposta pelo fato de o banco de dados eventualmente não dar
suporte à flexibilidade e agilidade exigidas pelas organizações modernas.
5. POR QUE USAR BANCOS DE DADOS DISTRIBUÍDOS?

A tarefa de gerenciamento de bancos de dados distribuídos apresenta diversas vantagens,
tais como: diferentes níveis de transparência, confiabilidade e disponibilidade, e desempenho.
A Tabela 1 traça um paralelo sobre as vantagens e as desvantagens do uso dos SGBDDs. Acom-
panhe:
Tabela 1 Vantagens e desvantagens do SGBDD.

VANTAGENS DESVANTAGENS
• Os dados ficam localizados próximos ao local de maior • Complexidade de gerenciamento e controle: as aplicações
demanda. devem reconhecer a localização dos dados e ter a
capacidade de integrá-los a partir de vários locais. É
• Maior rapidez de acesso aos dados: os usuários finais necessário que os administradores tenham capacidade de
costumam trabalhar apenas com um subconjunto dos coordenar as atividades do banco de dados, evitando sua
dados da empresa, armazenado localmente. degradação em função de anomalias.
• Maior rapidez de processamento de dados: um SGBDD • Dificuldade tecnológica: é necessário tratar e solucionar
divide a carga de trabalho do sistema, processando dados a integridade de dados, o gerenciamento de transações,
em vários locais. o controle da concorrência, o backup, a recuperação, a
otimização de consultas, a seleção do caminho de acesso,
• Facilidade de ampliação: possibilidade de adição de novos entre outras.
locais à rede sem afetar as operações de outros locais.
• Segurança: a probabilidade de falhas de segurança
• Aprimoramento das comunicações: como os sites locais aumenta quando os dados são armazenados em vários
são menores e mais próximos dos clientes, promovem locais. A responsabilidade do gerenciamento dos dados
melhor comunicação entre os departamentos e entre os será compartilhada por diferentes pessoas em diversos
clientes e a equipe da empresa. locais.
• Custos operacionais reduzidos: do ponto de vista dos • Falta de padrões: não há protocolos de comunicação
custos, é mais eficiente adicionar estações de trabalho a padronizados no nível de banco de dados. Ou seja,
uma rede do que atualizar um sistema de main-frame. diferentes fornecedores de banco de dados podem
empregar técnicas diferentes.
• Interface amigável: os PCs e as estações de trabalho
costumam ser equipados com interfaces gráficas de • Ampliação das necessidades de armazenamento e
usuário (GUI), sendo mais fácéis de operar. infraestrutura: são necessárias cópias de dados em
diferentes locais, exigindo, assim, espaço adicional de
armazenamento em disco.
VANTAGENS DESVANTAGENS
• Menor risco de falha em ponto único: quando um • Aumento com custos de treinamento: os custos com
componente dos computadores falha, o trabalho é treinamento costumam ser mais elevados em modelos
mantido por outras estações. Os dados também são distribuídos do que em centralizados.
distribuídos em vários locais.
• Custos: os bancos de dados distribuídos exigem
• Independência do processador: o usuário final é capaz infraestrutura duplicada para operar.
de acessar todas as cópias disponíveis dos dados e suas
solicitações são processadas por qualquer processador no
local dos dados.
Diferentes níveis de transparência

O sistema de Banco de Dados Distribuídos exige características funcionais que podem ser
agrupadas e descritas como recursos de transparência. Esses recursos têm como objetivo pos-
sibilitar que o usuário acredite que está trabalhando com um SGBD centralizado, de modo que
toda a complexidade de sistemas distribuídos seja oculta.
A transparência está relacionada com aquilo que não se vê. Transparência, nesse contex-
to, significa que o usuário final não tem ideia de onde ele está acessando os dados, se é de SP, RJ
ou MG, por exemplo. Ou seja, para esse tipo de usuário o acesso é transparente, sem evidenciar
nenhum tipo de complexidade. Isso significa, por exemplo, esconder os detalhes sobre o local
de armazenamento dos arquivos.
Os recursos de transparência dos SGBDDs podem ser descritos como:
1) Transparência de distribuição: permite que um banco de dados distribuído seja trata-
do como um único banco lógico. Se o SGBDD apresenta transparência de distribuição,
o usuário não precisa saber que os dados estão particionados.
2) Transparência de transação: permite que uma transação atualize os dados em mais
de um local de rede. Essa transparência garante que a transação seja inteiramente
concluída ou abortada, mantendo-se, assim, a integridade do banco de dados.
3) Transparência de falhas: garante que o sistema continue a operar no caso de falha de
um nó. As funções perdidas em função da falha serão recuperadas por outro nó da
rede.
4) Transparência de desempenho: permite que o sistema apresente um desempenho
compatível com o de um SGBD centralizado. O sistema não sofrerá qualquer degra-
dação de desempenho em função de sua utilização em rede ou de diferenças de pla-
taforma da rede. A transparência de desempenho também garante que o sistema en-
contre o caminho mais eficiente para acessar dados remotos.
5) Transparência de heterogeneidade: permite a integração de SGBD locais diferentes
sob um esquema comum ou global a todos. O SGBDD é responsável pela tradução das
solicitações de dados do esquema global para o esquema do SGBD local.
6) Transparência de replicação: imagine que os dados possam ficar armazenados em
locais diferentes, por exemplo, por uma questão de facilidade de acesso. No caso da
transparência de replicação, o usuário não sabe que existem cópias espalhadas por
locais diferentes. Para ele, é como se os dados estivessem sempre no mesmo lugar.
7) Transparência de fragmentação: em uma relação formada por tuplas e colunas de
atributos, é possível que ela seja fragmentada. Há dois tipos de fragmentação:
a) Fragmentação horizontal: divide a relação em conjuntos de tuplas, ou seja, por
linhas.
b) Fragmentação vertical: divide a relação em conjuntos de atributos (colunas). Ao
realizar uma consulta, o usuário não tem conhecimento dos fragmentos.

Confiabilidade e disponibilidade
Confiabilidade e disponibilidade são atributos que tendem a aumentar quando os dados
estão distribuídos.
A confiabilidade é a probabilidade de que, em um determinado momento, o sistema es-
teja em funcionamento.
Já a disponibilidade é a probabilidade de que, em um determinado intervalo de tempo, o
sistema esteja continuamente operante.
Se os dados estiverem armazenados em apenas um local, é mais fácil que o sistema fique
inoperante por determinado tempo. Portanto, na forma distribuída, se em um local houver al-
gum problema, os dados podem ser acessados de outro local, o que aumenta a confiabilidade
e a disponibilidade no sistema.
Desempenho
O desempenho em um banco de dados aumenta quando os dados estão localizados mais
próximos dos locais em que eles são necessários. Isso acontece porque a disputa pela CPU é
reduzida. Portanto, é função dos SGBDDs fragmentar o banco de dados para deixá-lo mais perto
do local em que será utilizado.
6. PROCESSAMENTO DISTRIBUÍDO E BANCO DE DADOS DISTRIBUÍDO

No processamento distribuído, o processamento lógico do banco de dados é compartilha-
do entre dois ou mais locais fisicamente independentes, conectados por uma rede. Por exemplo,
a entrada e saída, a seleção e a validação de dados podem ser executadas em um computador,
e um relatório com base nesses dados pode ser criado em outro.
Um ambiente básico de processamento distribuído compartilha o trabalho do processa-
mento entre os locais conectados por uma rede de comunicação.
O banco de dados distribuído, por sua vez, armazena o banco relacionado logicamente por
dois ou mais locais físicos independentes. Esses locais são conectados por meio de uma rede de
computadores. Em um SGBDD, o banco é composto de várias partes conhecidas como fragmen-
tos de banco de dados, que se localizam em locais diferentes e podem ser replicados em vários
desses locais. Cada fragmento é gerenciado por seu processo de banco de dados local.
Veja, na Figura 2, um exemplo de Banco de Dados Distribuído.
Figura 2 Ambiente de banco de dados distribuído.
Conforme pode ser observado na Figura 2, este exemplo de banco de dados está dividido
em três fragmentos (E1, E2 e E3), situados em locais diferentes. Verifica-se que os computado-
res estão conectados por um sistema de rede. Neste ambiente de distribuição, os usuários em
questão não precisam saber onde se situam as informações acessadas por eles; tudo ocorre de
forma transparente.
Autonomia local
A autonomia local pode ser entendida como um ambiente onde os sites específicos, em
meio a um sistema distribuído, sejam autônomos. Ou seja, todas as configurações e customiza-
ções de um site específico podem ser manipuladas diretamente no mesmo, de modo que estas
alterações não implicarão no ambiente distribuído como um todo. Por exemplo, consideremos
um site A em que este tenha dependência de um site B. Considerando o conceito de autonomia
local, entende-se que alterações realizadas no site B, não devem inferir no site A.
A autonomia local também implica que dados locais são de propriedade e gerenciamento
locais, com contabilidade local: todos os dados realmente pertencem a algum banco de dados
local, mesmo que sejam acessíveis a partir de outros sites remotos. Desta forma, temáticas rela-
tivas à segurança, integridade e representação de armazenamento de dados locais permanecem
sob o controle e o domínio do site local.
Muito embora o conceito de autonomia local implique em total independência entre sis-
temas, este conceito não é efetivamente realizável. Em diversas situações é verificado que um
site A qualquer tem de conceder relativo controle a um site B. Desta forma, um melhor conceito,

mais prático e contextual de autonomia local, pode ser entendido como o modo em que os sites
devem possuir sua autonomia de forma mais extensível quão possível.
É importante saber que, em um sistema distribuído, os distintos pontos de localização de
dados podem ser denominados por: nós, site, ponto de distribuição, entre outros.
Não dependência de um site central

Conforme verificou-se na autonomia local, esta pressupõe que todos os sites possam ser
manipulados de forma não distinta, ou seja, não devem haver dependências entre um site dito
como "mestre" central, que disponibilize serviços centralizados. Desta forma, cria-se um am-
biente de não dependência, de modo que o ambiente sistêmico não tenha seu funcionamento
dependente de um ente central único, assim, pode ser assegurada a maior disponibilidade do
ambiente como um todo.
Observa-se que a não dependência de um site central nada mais é que uma consequência
da autonomia local, pois se o primeiro for realizado, o segundo virá em seguida. Porém, a não
dependência de um site central é desejável por si só, mesmo que não seja alcançada de modo
a contemplar a autonomia local.
A dependência de um site central seria indesejável pelo menos por duas razões: primeiro,
o site central poderia ser um gargalo; segundo, e mais importante, o sistema seria vulnerável (se
o site central ficasse indisponível por um dado período de tempo, todo o sistema cairia).
Fragmentação de dados
Vimos, no tópico anterior, os conceitos de fragmentação horizontal e fragmentação verti-
cal. Observe que a forma mais simples de fragmentação considera apenas um banco de dados,
sem replicação, ou seja, cada relação do banco (ou apenas parte dela) será armazenada em um
local.
A fragmentação ocorre, especialmente, para otimização de armazenamento de dados e
desempenho, ou seja, uma informação pode ser "dividida em pedaços" ou fragmentos. Os frag-
mentos, por sua vez, podem ser armazenados em locais distintos, de modo que uma dada infor-
mação que venha a ser mais utilizada pelo sistema, por exemplo, seja armazenada localmente,
minimizando-se assim o trafego de rede, por exemplo.
Há, ainda, a fragmentação mista, que consiste na combinação da fragmentação horizontal
com a vertical.
Uma fragmentação na horizontal acontece com o uso de uma operação SELECT, enquan-
to uma fragmentação na vertical é obtida com o uso de uma operação PROJECT.
Para conhecer os fragmentos e as suas localizações, podemos utilizar dois esquemas im-
portantes. São eles:
• Esquema de fragmentação: define um conjunto dos fragmentos com todos os atribu-
tos e tuplas do banco de dados. Dessa forma, se for necessário, é possível reconstruir
o banco de dados inteiro.
• Esquema de alocação: funciona como um tipo de mapeamento que indica o local em
que cada fragmento está armazenado.
Replicação de dados
De acordo com Date (2003), um sistema admite replicação de dados se uma dada variável
de relação armazenada, ou um dado fragmento de uma variável de relação armazenada, pode
ser representado por muitas cópias ou réplicas distintas, armazenadas em sites distintos.
São três as formas como podem acontecer a replicação dos dados de um banco de dados,
a saber: total, parcial ou nenhuma.
A replicação é desejável por pelo menos duas razões:
1) Pode significar melhor desempenho (aplicações podem operar sobre cópias locais, em
vez de terem de se comunicar com sites remotos).
2) Também pode significar melhor disponibilidade (um dado objeto replicado permane-
ce disponível para processamento enquanto houver no mínimo uma cópia disponível).
Naturalmente, a maior desvantagem da replicação é que, quando um determinado objeto
replicado é atualizado, todas as cópias desse objeto precisam ser atualizadas; o problema da
propagação de atualizações.
A replicação total é conhecida como banco de dados distribuído completamente replica-
do. Nesse caso, o banco de dados inteiro é replicado para todos os sites do sistema distribuído.
A vantagem desse tipo de replicação é o aumento da disponibilidade dos dados, pois basta que
um dos sites esteja em funcionamento para se ter acesso aos dados do banco. Entretanto, são
desvantagens a redução da velocidade das operações de atualização (o cuidado está em manter
todas as cópias replicadas consistentes) e o fato de as técnicas de controle de concorrência e de
recuperação serem mais caras.
A Figura 3 ilustra a replicação dos dados em um SGBDD:
Figura 3 Replicação de dados.
A Figura 3 demonstra a seguinte situação: suponha que o banco de dados A seja dividido
em dois fragmentos, A1 e A2. Dentro de um banco de dados distribuído replicado, por exemplo,
o cenário ilustrado pela Figura 3, é possível que o fragmento A1 seja armazenado nos locais S1
e S2, enquanto A2 é armazenado nos locais S2 e S3.
Embora a replicação traga benefícios, também impõe cargas adicionais ao processamento
ao SGBDD, pois cada cópia de dados deve ser mantida pelo sistema. Além disso, como dados
são replicados em outro local, há custos associados de armazenamento e ampliação dos tempos
transacionais.
O contrário dessa forma é aquela na qual não há replicação alguma, conhecida como ne-
nhuma replicação.
A terceira forma, e a mais utilizada, é a replicação parcial dos dados, isto é, alguns frag-
mentos do banco de dados podem ser replicados e outros, não.
Até aqui, você teve a possibilidade de compreender que um esquema de replicação des-
creve como os fragmentos estão replicados. Veja, a seguir, o que é alocação de dados.
Alocação de dados
Refere-se à atribuição de um fragmento a um site, ou seja, determina o local em que um
fragmento ou suas cópias deverão ficar. Essa é a própria definição de distribuição de dados. São
estratégias de alocação:
• Alocação centralizada de dados: todo banco de dados é armazenado em um único
local.
• Alocação particionada de dados: o banco de dados é divido em duas ou mais partes se-
paradas, denominadas fragmentos, as quais são armazenadas em dois ou mais locais.
• Alocação replicada de dados: cópias de um ou mais fragmentos do banco de dados são
armazenadas em vários locais.
Considere um banco de dados para uma determinada universidade. Ele contém informa-
ções sobre os alunos, as matrículas, os professores, os funcionários, os departamentos, os labo-
ratórios, as bibliotecas etc. No entanto, as pessoas que acessam o banco têm diferentes interes-
ses sobre os dados armazenados.
Imagine que essa universidade tenha mais de um campus. Dessa forma, é necessário que
os dados estejam distribuídos pelos diferentes campi em seus respectivos sites. Supomos, ainda,
que em determinado campus não haja necessidade de que todos os atributos ou tuplas de uma
relação estejam presentes. Nesse caso, deve-se utilizar o recurso da fragmentação, que parti-
cionará as relações na vertical (atributos) ou na horizontal (tuplas). Os fragmentos obtidos são,
então, distribuídos aos diferentes sites. Pode acontecer, também, de não haver fragmentação e,
nesse caso, a relação inteira será replicada.
Chamamos o ato de distribuir esses fragmentos ou relações pelos sites de alocação.
7. CLASSIFICAÇÃO DOS SGBDDS

Os Sistemas Gerenciadores de Banco de Dados Distribuídos (SGBDDs) podem ser classifi-
cados segundo algumas características peculiares a cada um. Observe a seguir:
Quanto ao grau de homogeneidade

Ocorre a classificação quanto ao grau de homogeneidade quando todos os servidores uti-
lizam um software idêntico e quando todos os clientes também utilizam um software idêntico.
Nesse caso, o SGBDD é considerado homogêneo. Caso contrário, é considerado heterogêneo.
Quanto ao grau de autonomia local

A classificação quanto ao grau de autonomia local refere-se ao fato de poder ou não aces-
sar diretamente o servidor para transações locais. Se não houver essa permissão, o sistema não
tem autonomia local. Caso contrário, o sistema tem autonomia local.
Um SGBDD pode, ainda, ser classificado como federado. Isso significa que o servidor é um
SGBD com muita autonomia, com seus próprios usuários, transações e, até, DBA.
8. CONSULTAS EM BANCO DE DADOS DISTRIBUÍDO

Ao realizar consultas em banco de dados distribuídos, podemos considerar os sistemas
centralizados, em que o número de acessos a disco é um fator utilizado para mensurar o custo
de consultas. Já para os sistemas distribuídos, outros fatores devem ser considerados na mensu-
ração do custo das consultas, tais como o custo de transmissão de dados na rede, por exemplo.
Ao se executar uma consulta, é necessário observar se a relação a ser consultada é repli-
cada; caso seja, é preciso escolher a réplica. É necessário, também, considerar se a réplica é ou
não fragmentada, pois caso a réplica o seja, o custo da consulta aumentará.
A escolha da estratégia para realizar o processamento de uma consulta depende de alguns
fatores, como o volume de dados a ser transportado e o custo de transmissão, por exemplo; e,
por isso, uma estratégia não pode ser apontada como sendo melhor que a outra.
Observe, a seguir, algumas questões inerentes à consulta em meio a um SGBDD, citadas
por Date (2003):
Consideremos uma consulta que tem por objetivo obter fornecedores de peças vermelhas em Londres.
Suponha que o usuário esteja no site de Nova York e que os dados estejam armazenados no site de
Londres. Suponha também que existem vários fornecedores que satisfazem à solicitação. Se o sistema
for relacional, a consulta envolverá basicamente duas mensagens: uma (a) para enviar a solicitação de
Nova York para Londres e outra (b) para retornar o conjunto de resultados de n tuplas de Londres para
Nova York. Se, por outro lado, o sistema não for relacional, mas sim um sistema de record-at-a-time,
a consulta envolverá basicamente 2n mensagens: (a) n de Nova York para Londres solicitando "o pró-
ximo" fornecedor, e (b) n de Londres para Nova York, a fim de retornar "o próximo" fornecedor. Dessa
forma, o exemplo ilustra o fato de que o sistema relacional provavelmente superará um sistema não
relacional em desempenho, possivelmente por várias ordens de grandeza.
A otimização é ainda mais importante em um sistema distribuído do que em um sistema centraliza-
do. O detalhe importante é que, em uma consulta como a anterior, envolvendo diversos sites, haverá
muitos modos possíveis de mover os dados pelo sistema de maneira a satisfazer à solicitação e, é de
importância crucial que se encontre uma estratégia eficiente. Por exemplo, uma solicitação de união
de uma relação Rx armazenada no site X e uma relação Ry armazenada no site Y poderia ser executada
movendo-se Rx para Y ou movendo-se Ry para X, ou ainda movendo-se ambas para um terceiro site Z.
Para resumir rapidamente o exemplo, são analisadas seis diferentes estratégias para processamento da
consulta sob certo conjunto de hipóteses plausíveis, e o tempo de resposta varia de um mínimo de um
décimo de segundo a um máximo de aproximadamente seis horas! Portanto, a otimização é claramente
crucial e esse fato, por sua vez, pode ser visto como mais uma razão pela qual os sistemas distribuídos
são sempre relacionais (observando-se que as solicitações relacionais podem ser otimizadas enquanto
as solicitações não relacionais não podem).
9. TRANSAÇÕES DISTRIBUÍDAS
Da mesma forma que as transações locais devem preservar as propriedades ACID, as tran-
sações distribuídas também o devem.
Conforme já estudamos na Unidade 6, o termo ACID refere-se às propriedades das transa-
ções, impostas pelo controle de concorrência e significa: Atomicidade, Consistência, Isolamento
e Durabilidade.
Relembraremos o que já foi estudado: as transações locais acessam e atualizam apenas o
banco de dados local, enquanto as distribuídas (ou globais) acessam e atualizam diversos ban-
cos de dados locais. Por esse motivo, é mais difícil a preservação das propriedades ACID, uma
vez que vários sites podem estar envolvidos no processo.

Não devemos nos esquecer de que as transações podem falhar e, se isso ocorrer no mo-
mento em que muitos sites estiverem envolvidos na execução, o processamento pode terminar
em erro.
10. CONTROLE DE CONCORRÊNCIA E DE RECUPERAÇÃO

Problemas que podem surgir nos sistemas distribuídos e que não ocorrem nos sistemas
centralizados estão relacionados com o controle de concorrência e de recuperação. Mas como
esses tópicos já foram apresentados e discutidos nas unidades anteriores, esse conteúdo será
abordado novamente, mas aplicado aos sistemas distribuídos. São eles: múltiplas cópias, falhas
de sites, falhas de comunicação e commit distribuído. Vejamos, a seguir, cada um deles.
Múltiplas cópias
Os sistemas distribuídos possuem múltiplas cópias de seus dados, as quais estão espalha-
das por diferentes sites. O controle de concorrência é responsável por manter a consistência
dessas cópias.
Falhas de sites
Se um site falhar, o SGBDD deve continuar operando com os demais sites e, quando um
site for recuperado, o banco de dados local deve ser atualizado.
Falhas de comunicação
As falhas de comunicação são falhas que ocorrem nos links de comunicação entre os sites,
e cabe ao sistema lidar com essas quebras.
Commit distribuído
O commit distribuído refere-se aos problemas que podem surgir caso uma transação es-
teja acessando bancos de dados armazenados em vários sites, e algum desses sites falhar no
momento do commit da transação. Nesses casos, utiliza-se o protocolo commit de duas fases,
capaz de tratar esse tipo de problema.
As falhas em sistemas distribuídos estão relacionadas com problemas que ocorrem nas
redes de computadores e, especificamente nesse caso, com a forma como os sites estão conec-
tados. Pense nas topologias de rede: agora, imagine que cada site seja um nó da rede. As dife-
rentes topologias de rede possuem características diferentes quanto às falhas e, dependendo da
topologia, uma falha em um único nó pode particionar a rede, enquanto, em outra topologia,
por exemplo, é necessário que mais de um nó falhe para que a rede seja particionada.
Desse modo, podemos dizer que um sistema distribuído que consegue detectar falhas é
considerado robusto. É desejável, ainda, que ele tenha a capacidade de reconfigurar o sistema e
possa continuar funcionando, e que recupere seu estado original. Os processos de recuperação
de falhas nos sistemas distribuídos são mais complexos do que para sistemas centralizados.
Os métodos de controle de concorrência distribuída são uma extensão das técnicas utili-
zadas para o controle de concorrência dos bancos de dados centralizados.
A ideia geral é que cada item de dados tenha o que se chama de cópia distinta, de forma
que todas as operações de bloqueio e desbloqueio sejam realizadas nessa cópia. A ideia da có-
pia distinta é geral para todas as técnicas. No entanto, cada técnica possui sua forma de escolher
as cópias distintas.
Apresentamos, a seguir, algumas técnicas utilizadas no controle de concorrência distribu-
ída, com base na cópia distinta:
Site primário
Um dos sites é escolhido para ser o coordenador das solicitações de bloqueio e desblo-
queio (como na técnica sobre o bloqueio centralizado).
Site primário com site de backup

Com a intenção de eliminar a sobrecarga de solicitações impostas ao site primário, um
segundo site é escolhido para ser o backup. Caso haja falhas no primeiro site, o segundo é acio-
nado.
Cópia primária
O objetivo da cópia primária é que a carga de bloqueio seja distribuída por vários sites, de
forma que as cópias distintas fiquem armazenadas em diferentes sites. Dessa forma, se um site
falhar, serão afetadas apenas as transações que estejam acessando bloqueios para as cópias do
site afetado. As demais transações nada sofrerão.
Além da concorrência distribuída com base em cópias distintas, existe, ainda, o controle
de concorrência distribuída baseada em votação e o processo de recuperação distribuída. A téc-
nica de votação não trabalha com cópias distintas. A solicitação de bloqueio é enviada a todos
os sites que possuam uma cópia do item de dados, e aos sites cabe conceder ou negar o pedido.
Para a transação ter seu pedido atendido, é necessário que a maior parte das cópias dos itens de
dados conceda a permissão de bloqueio solicitada pela transação. Caso contrário, a solicitação
é cancelada.
Não será abordado aqui o processo de recuperação distribuída devido a sua complexida-
de. Segundo Elmasri e Navathe (2005, p. 595), "o processo de recuperação em bancos de dados
distribuídos é bastante complicado."

unidade:
1) Por que usar Bancos de Dados Distribuídos?
2) Quais são os principais tipos de fragmentação de dados?
3) Quando a replicação torna-se desejável?
4) Como você pode implementar um Banco de Dados Distribuído utilizando o PostgreSQL?
12. CONSIDERAÇÕES FINAIS

Nesta unidade, você teve a oportunidade de estudar alguns conceitos básicos sobre Ban-
cos de Dados Distribuídos.

Conceituamos os Sistemas de Bancos de Dados Distribuídos e suas principais aplicações.

Estudamos, também, características importantes deste conceito de dados, tais como confiabili-
dade e desempenho.
Foram apresentadas as principais características do processamento de dados distribuídos,
e alguns conceitos como autonomia local, replicação de dados, fragmentação e alocação de
dados. Por fim, citamos o devido modo de controle de concorrência e recuperação dos dados.
Por se tratar de um assunto extenso, sugerimos que você aprofunde seus conhecimentos
realizando a leitura das bibliografias indicadas nas referências.
Alguns dos conceitos já haviam sido apresentados para sistemas centralizados. Observe
que o fundamento é o mesmo para sistemas distribuídos. Entretanto, por ser um tipo de sistema
mais complexo, os processos que o envolvem são mais difíceis de serem tratados.
Você pôde estudar, também, os conceitos de fragmentação e replicação/alocação de da-
dos, que são específicos para Bancos de Dados Distribuídos. Em relação às consultas, algumas
considerações são importantes, pois os dados acessados podem não estar apenas em um site,
mas distribuídos por vários outros, o que pode influenciar no custo dessas consultas.
E, para encerrar, você pôde compreender como os conceitos de controle de transações,
concorrência e recuperação (assuntos tratados anteriormente) são aplicados aos Bancos de Da-
dos Distribuídos.

DATE, C. J. Introdução a Sistemas de Banco de Dados. 8 ed. Tradução de Daniel Vieira. Rio de Janeiro: Elsevier, 2003.
ROB, P.; CORONEL, C. Sistemas de Banco de Dados – projeto, implementação e administração. São Paulo: Cengage Learning,
2011.
© Apêndices 257
Apêndice 1
Instalação do PostgreSQL
1. APRESENTAÇÃO
Neste Apêndice, você terá a oportunidade de conhecer os procedimentos relativos à ins-
talação do PostgreSQL, que será utilizado durante o decorrer deste estudo
É importante ressaltar que para a construção deste Apêndice foram utilizadas informações
do próprio site do PostgreSQL, disponível em: <http://www.postgresql.org.br>. Acesso em: 23
out. 2012.
O PostgreSQL é um Sistema de Gerenciamento de Banco de Dados Objeto-Relacional ba-
seado no Postgres versão 4.2, desenvolvido pelo Departamento de Ciência da Computação da
Universidade da Califórnia, em Berkeley. O Postgres foi pioneiro em vários conceitos que se tor-
naram disponíveis somente bem mais tarde, em alguns sistemas de banco de dados comerciais.
O PostgreSQL é um descendente de código-fonte aberto do código original de Berkeley,
que suporta grande parte do padrão SQL e oferece muitas funcionalidades modernas, como:
1) Comandos complexos.
2) Chaves estrangeiras.
3) Gatilhos.
4) Visões.
5) Integridade transacional.
6) Controle de simultaneidade multiversão.
Além disso, o PostgreSQL pode ser ampliado pelo usuário de muitas maneiras como, por
exemplo, adicionando:
1) Tipos de dado.
2) Funções.
3) Operadores.
4) Funções de agregação.
5) Métodos de índice.
6) Linguagens procedurais.
Devido à sua licença liberal, o PostgreSQL pode ser utilizado, modificado e distribuído
por qualquer pessoa para qualquer finalidade, seja particular, comercial ou acadêmica, livre de
encargos.
Histórico
O Sistema de Gerenciamento de Banco de Dados Objeto-Relacional, hoje conhecido por
PostgreSQL, é derivado do pacote Postgres escrito na Universidade da Califórnia, em Berkeley.
Com mais de uma década de desenvolvimento, o PostgreSQL é atualmente o mais avançado
banco de dados de código aberto disponível.
O projeto Postgres, liderado pelo Professor Michael Stonebraker, foi patrocinado pela Defen-
se Advanced Research Projects Agency (DARPA), pelo Army Research Office (ARO), pela National
Science Foundation (NSF)) e pela ESL, Inc. A implementação do Postgres começou em 1986. Os

conceitos iniciais para o sistema foram apresentados em The design of Postgres, e a definição do
modelo de dados foi descrita em The Postgres data model. O projeto do sistema de regras desta
época foi detalhado em The design of the Postgres rules system, e os fundamentos lógicos e a ar-
quitetura do gerenciador de armazenamento, em The design of the Postgres storage system.
O Postgres passou por várias versões principais desde então. A primeira versão de de-
monstração do sistema se tornou operacional em 1987, e foi exibida em 1988 na Conferência
ACM-SIGMOD. A versão 1, descrita em The implementation of Postgres, foi liberada para alguns
poucos usuários externos em junho de 1989. Em resposta à crítica ao primeiro sistema de re-
gras, e a versão 2 foi liberada em junho de 1990, contendo um novo sistema de regras. A versão
3 surgiu em 1991, adicionando suporte a múltiplos gerenciadores de armazenamento, um exe-
cutor de comandos melhorado, e um sistema de regras reescrito. Em sua maior parte, as versões
seguintes, até o Postgres95, focaram a portabilidade e a confiabilidade.
O Postgres tem sido usado para implementar muitos aplicativos diferentes de pesquisa
e de produção, incluindo: sistema de análise de dados financeiros, pacote de monitoração de
desempenho de motor a jato, banco de dados de acompanhamento de asteróides, banco de da-
dos de informações médicas, e vários sistemas de informações geográficas. O Postgres também
tem sido usado como ferramenta educacional por várias universidades. Por fim, a Illustra Infor-
mation Technologies (posteriormente incorporada pela Informix, que agora pertence à IBM)
apossou-se do código e o comercializou. O Postgres se tornou o gerenciador de dados principal
do projeto de computação científica Sequoia 2000, no final de 1992.
O tamanho da comunidade de usuários externos praticamente dobrou durante o ano de
1993. Começou a ficar cada vez mais óbvio que a manutenção do código do protótipo e o su-
porte estavam consumindo grande parte do tempo que deveria ser dedicado a pesquisas de
banco de dados. Em um esforço para reduzir essa sobrecarga de suporte, o projeto do Postgres
de Berkeley terminou oficialmente na versão 4.2.
O Postgres95
Em 1994, Andrew Yu e Jolly Chen adicionaram um interpretador da linguagem SQL ao
Postgres. Sob um novo nome, o Postgres95 foi, em seguida, liberado na web para encontrar seu
próprio caminho no mundo, como descendente de código aberto do código original do Postgres
de Berkeley.
O código do Postgres95 era totalmente escrito em ANSI C, com tamanho reduzido em
25%. Muitas mudanças internas melhoraram o desempenho e a facilidade de manutenção. O
Postgres95 versão 1.0.x era 30 a 50% mais rápido que o Postgres versão 4.2, pelo Wisconsin
Benchmark. Além da correção de erros, vejamos as principais melhorias descritas a seguir.
1) A linguagem de comandos PostQUEL foi substituída pela linguagem SQL (implemen-
tada no servidor). Não foram permitidas subconsultas até o PostgreSQL, mas estas
podiam ser simuladas no Postgres95, por meio de funções SQL definidas pelo usuário.
As funções de agregação foram reimplementadas. Também foi adicionado suporte a
cláusula GROUP BY nas consultas.
2) Foi fornecido um novo programa para executar comandos SQL interativos, o psql, uti-
lizando o Readline do GNU, que substituiu com vantagens o programa monitor antigo.
3) A interface para objetos grandes foi revisada. A inversão de objetos grandes era o
único mecanismo para armazená-los (o sistema de arquivos inversão foi removido).
4) O sistema de regras no nível de instância foi removido. As regras ainda eram disponí-
veis como regras de reescrita.
© Apêndices 259
5) Um breve tutorial introduzindo as funcionalidades regulares da linguagem SQL, assim

como as do Postgres95, foi distribuído junto com o código-fonte.
6) O utilitário make do GNU (em vez do make do BSD) foi utilizado para a geração. Além
disso, o Postgres95 podia ser compilado com o GCC sem correções (o alinhamento de
dados para a precisão dupla foi corrigido).
O PostgreSQL
Em 1996 ficou claro que o nome Postgres95 não resistiria ao teste do tempo. Foi escolhido
um novo nome, PostgreSQL, para refletir o relacionamento entre o Postgres original e as versões
mais recentes com capacidade SQL. Ao mesmo tempo, foi mudado o número da versão para
começar em 6.0, colocando a numeração de volta à sequência original começada pelo projeto
Postgres de Berkeley.
A ênfase durante o desenvolvimento do Postgres95 era identificar e compreender os pro-
blemas existentes no código do servidor. Com o PostgreSQL, a ênfase foi reorientada para o
aumento das funcionalidades e recursos, embora o trabalho continuasse em todas as áreas.
Instalação do PostgreSQL
O PostgreSQL pode ser obtido pelo site de sua organização mantenedora, disponível em:
<http://www.postgresql.org.br/downloads>. Acesso em: 23 out. 2012.
Ao acessar o endereço, deverá ser apresentada uma página similar à Figura 1. Veja:
Figura 1 Página de download do PostgreSQL.

Por se tratar de um sistema portável, ou seja, pode ser utilizado em diversos sistemas
operacionais, temos que escolher a versão adequada ao uso. Este Apêndice adotará o ambiente
Windows como padrão. Conforme pode ser observado na Figura 1, a área em destaque contém
as versões do SGBD para cada sistema operacional. Selecione aquele que atenderá suas neces-
sidades.
A etapa seguinte à seleção do sistema operacional levará à página exibida pela Figura 2.
Figura 2 Pacotes para download do SGBD PostgreSQL.
Selecione a opção de download gerenciado pelo installer do sistema Windows, conforme

indicado na Figura 2.
A próxima etapa nos permitirá a escolha da versão do sistema operacional. Veja na Figura 3:
© Apêndices 261
Figura 3 Opções de sistemas operacionais do instalador do PostgreSQL.
Utilizaremos a versão 9.04 do PostgreSQL para o ambiente Windows. Proceda a seleção

da opção de acordo com a indicação da Figura 3. Observe que optamos pela instalação do Post-
greSQL para Windows 32 bits.
Realizada a escolha da opção da versão do SGBD para um determinado sistema operacio-
nal, o download deverá ser iniciado automaticamente. Escolha um diretório para que o instala-
dor seja salvo e aguarde o término do download.
Terminado o download, execute o arquivo de instalação com um clique duplo no item
representado na Figura 4.
Figura 4 Escolha da versão.
A primeira janela das etapas de instalação é demonstrada na Figura 5. Acompanhe:

Figura 5 Início do processo de instalação.
Conforme indicado na Figura 5, acione o botão Next, para avançarmos para a etapa se-
guinte.
O próximo passo refere-se ao diretório onde o PostgreSQL deverá ser instalado, conforme
mostrado na Figura 6.
Figura 6 Diretório para instalação.

© Apêndices 263
Manteremos o diretório padrão; caso queira/necessite alterá-lo, informe-o adequada-

mente e, em seguida, acione o botão Next.
A etapa seguinte define o diretório onde ficarão armazenados os arquivos pertinentes a
cada banco de dados que será criado. Conforme mostra a Figura 7, manteremos a opção padrão;
altere-a se for necessário e, em seguida, selecione Next.
Figura 7 Diretório para armazenamento dos bancos de dados.
Chegamos a uma etapa muito importante para o SGBD: a definição da senha do supe-
rusuário, aquele que conterá os privilégios totais quanto ao SGBD, denominado por Postgres.
Como o banco de dados será para uso de estudo e aprendizado, e não para rodar uma aplicação
crítica, recomendamos o uso de uma senha fácil (123456). Preencha a senha e sua confirmação
conforme indicado na Figura 8.

Figura 8 Definição de senha.
Definida a senha e feita sua confirmação, certifique-se de memorizá-la. Prossiga acionan-

do o botão Next.
Deve-se definir uma porta do sistema operacional para ser utilizada pelo SGBD. Por pa-
drão, o PostgreSQL utiliza a porta 5432, conforme demonstrado na Figura 9. Observe:
Figura 9 Definição da porta.

© Apêndices 265
Caso necessite utilizar outra porta, você deverá informá-la neste momento. Manteremos
a porta padrão. Prossiga acionando Next.
A última definição refere-se ao locale que o banco deverá suportar. Manteremos o padrão,
conforme indicado na Figura 10.
Figura 10 Definição do locale.
Mantendo-se a opção padrão, ou tendo selecionado algum locale específico, acione o bo-
tão Next.
Você será informado que o PostgreSQL está pronto para ser instalado. Ciente disto, sele-
cione a opção Next novamente, conforme Figura a 11.

Figura 11 Confirmação de instalação.
Será dado início ao processo de instalação, conforme demonstrado na Figura 12. Aguarde
até seu término.
Figura 12 Status de instalação.
Ao término do processo será exibida a seguinte janela, conforme mostra a Figura 13.
© Apêndices 267
Figura 13 Término da instalação.
Como pode ser observado na Figura 13, desmarque a opção Launch Stack Build e clique
no botão Finish. Neste momento sua máquina já deverá dispor do PostgreSQL instalado.
O PostgreSQL tem um bom gerenciado nativo, o pgAdminIII. Localize-o no menu Iniciar de
seu sistema e acesse-o.
A interface do pgAdminIII é apresentada na Figura 14. Observe:
Figura 14 Interface do pgAdminIII.

Seu ambiente deverá estar semelhante ao apresentado na Figura 14. Dê um clique duplo
na opção indicada na Figura 15.
Figura 15 Primeiro acesso ao banco.
Será solicitada a senha definida anteriormente (como mostra a Figura 16). Informe-a.
Figura 16 Senha para acesso.
Ao informar a senha previamente definida, o acesso ao SGBD deverá ser disponibilizado.

Observe a Figura 17:
© Apêndices 269
Figura 17 Acesso ao SGBD.
A partir de agora, seu banco de dados PostgreSQL está devidamente instalado e pronto
para ser usado.
Bons estudos!
2. E-REFERÊNCIAS
Sites pesquisados
COMUNIDADE BRASILEIRA DE POSTGRESQL. Disponível em: <http://www.postgresql.org.br>. Acesso em: 23 out. 2012.
COMUNIDADE BRASILEIRA DE POSTGRESQL. Disponível em: <http://www.postgresql.org.br/downloads>. Acesso em: 23 out.
2012.

Apêndice 2
Álgebra Relacional
1. APRESENTAÇÃO
A álgebra relacional é uma coleção de operações que utiliza uma linguagem formal para
manipular as relações. Essas operações são utilizadas para selecionar tuplas de relações indivi-
duais e para combinar tuplas relacionadas de relações diferentes para especificar uma consulta
em um banco de dados.
O resultado de cada operação é uma nova operação, a qual também pode ser manipulada
pela álgebra relacional.
A seguir, veja algumas operações da álgebra relacional.
Operação Select
A operação select é utilizada para selecionar um subconjunto de tuplas de uma relação. As
tuplas devem satisfazer uma condição de seleção.
As operações relacionais que podem ser aplicadas na operação select são:
•
Além dos operadores booleanos:
• and, or, not.
A operação select é unária, ou seja, só pode ser aplicada a uma única relação. Não é pos-
sível aplicar a operação sobre tuplas de relações distintas.
A forma geral de uma operação select é:
s <condição de seleção> ( <nome da relação> )
Na qual:
• a letra grega s (sigma) é utilizada para representar a operação de seleção;
• a <condição de seleção> é uma expressão booleana aplicada sobre os atributos da
relação;
• o <nome da relação> é o nome da relação sobre a qual será aplicada a operação select.
Exemplo
Considere a entidade ALUNO, a seguir:
ALUNO (código, nome, sexo, nascimento, rua, número, bairro, cidade, estado)
Consulta = s <condição de seleção> ( <nome da relação> )
Selecione alunos do sexo feminino:

Alunas = s sexo= "feminino" (ALUNO)
© Apêndices 271
Em linguagem SQL:
SELECT * FROM aluno WHERE sexo = "feminino";
Selecione alunos do sexo feminino e residentes em Batatais:

Alunas = s (sexo= "feminino") and (cidade = "Batatais") (ALUNO)
Em linguagem SQL:
SELECT * FROM aluno WHERE sexo = "feminino" and cidade= "Batatais";
Operação Project
A operação project seleciona um conjunto determinado de colunas de uma relação. A
forma geral de uma operação project é:
p <lista de atributos> (<nome da relação>)
Na qual:
• a letra grega p (pi) representa a operação project;
• a <lista de atributos> representa a lista de atributos que o usuário deseja selecionar;
• o <nome da relação> representa a relação sobre a qual a operação project será aplicada.
Exemplo
Considere a entidade ALUNO, a seguir.
Consulta = p código, nome (ALUNO)
Em linguagem SQL:
SELECT código, nome FROM aluno;
As operações project e select podem ser utilizadas de forma combinada, permitindo que
apenas determinadas colunas de determinadas tuplas possam ser selecionadas
Exemplo
p <lista de atributos> (s <condição de seleção> ( <nome da relação> ))
p código, nome (ssexo= "feminino" (ALUNO))
Operações matemáticas
Levando em consideração que as relações podem ser tratadas como conjuntos, podemos,
então, aplicar operações matemáticas sobre as relações. Estas operações são: união ( ), inter-
secção ( ), diferença (-) e produto cartesiano (X).

As operações união, interseção e diferença devem ser passíveis de união. Duas relações
R(A1,A2, … , An) e S(B1, B2,…, Bn) são passíveis de união se têm o mesmo grau e domínio (A) =
domínio(B), para 1 <= i <= n.
Observe, a seguir, a definição destas operações.
1) União: o resultado desta operação representada por R S é uma relação T que inclui
todas as tuplas que se encontram em R e todas as tuplas que se encontram em S.
2) Intersecção: o resultado desta operação representada por R S é uma relação T que
inclui as tuplas que se encontram em R e em S ao mesmo tempo.
3) Diferença: o resultado desta operação representada por R - S é uma relação T que
inclui todas as tuplas que estão em R, mas não estão em S.
4) Produto cartesiano: o produto cartesiano de duas relações R X S combina cada tupla
de R com cada tupla de S. O resultado de R(A1, A2, , An) X S(B1, B2, , Bm) é uma re-
lação T com n + m atributos T(A1, A2, …, An, B1, B2, …,Bm). Se R tem x tuplas e S tem
y tuplas, então R X S terá x*y tuplas.
Exemplos
União
Considere a entidade ALUNO, a seguir.
Obtenha o nome e o sexo dos alunos cujo nascimento é igual a 29/02/1980.

cid_SP = p nome, sexo (s código >= 100 (ALUNO))
NOME SEXO
Carlos M
Paulo M
Fernanda F
cid_RC =p nome, sexo (s cidade= "Rio Claro" (ALUNO))

NOME SEXO
Carlos Rio Claro
Manoel Rio Claro
Resultado (NomeAluno, NascimentoAluno) ß cid_SP cid_RC

NOME CIDADE
Paulo São Paulo
Fernanda São Paulo
Carlos Rio Claro
Manoel Rio Claro
© Apêndices 273
Intersecção
Considere as entidades PROFESSOR E TUTOR.
PROFESSOR (código, nome, área, unidade)
TUTOR (código, nome, área, unidade)
Obtenha o nome e a área dos professores e tutores comuns à unidade de Batatais.

P= p nome, área (s unidade = "Batatais" (PROFESSOR))
PROFESSOR
NOME ÁREA
Alberto Silva Computação
Carlos Souza Matemática
Joaquim Nabuco Computação
Celso Prado Computação
T= p nome, área (s unidade = "Batatais" (TUTOR))
TUTOR
NOME ÁREA
Adelaide Almeida Matemática
Luiz Almeida Matemática
Resultado (Nome, Área) ß PROFESSOR – TUTOR

NOME ÁREA
Diferença
Considere as entidades PROFESSOR e TUTOR.
PROFESSOR (código, nome, área, unidade)

TUTOR (código, nome, área, unidade)
Obtenha o nome e a área dos professores que não são tutores na unidade de Batatais.
P= p nome, área (s unidade = "Batatais" (PROFESSOR))

PROFESSOR
NOME ÁREA
T= p nome, área (s unidade = "Batatais" (TUTOR))
TUTOR
NOME ÁREA
Adelaide Almeida Matemática
Luiz Almeida Matemática
Resultado (Nome, Área) ß PROFESSOR - TUTOR

NOME ÁREA
Produto cartesiano
Considere as entidades DISCIPLINA e ALUNO.
DISCIPLINA (código_disc, nome_disc, unidade)

ALUNO (código_aluno, nome_aluno)
DISCIPLINA
CÓDIGO_DISC NOME_DISC
1010 Banco de dados
1234 Lógica de programação
ALUNO
CÓDIGO_ALUNO NOME
32 José Carlos
34 Juliana Almeida
43 Luan Ribeiro
© Apêndices 275
DISCIPLINA X ALUNO
CÓDIGO_DISC NOME_DISC CÓDIGO_ALUNO NOME
1010 Banco de Dados 32 José Carlos
1234 Lógica de Programação 32 José Carlos
1010 Banco de Dados 34 Juliana Almeida
1234 Lógica de Programação 34 Juliana Almeida
1010 Banco de Dados 43 Luan Ribeiro
1234 Lógica de Programação 43 Luan Ribeiro
Operador Join
Join é uma das operações mais utilizadas na álgebra relacional e a forma mais comum de
combinar informação de duas ou mais relações.
Exemplo
Considere as relações R e S:
T= (R X <condição> S)
Produz uma relação com todas as combinações possíveis entre os registros da relação R
com a S condicionadas pela <condição>.
Pode-se dizer que:
(R X <condição> S) = s <condição> (R x S)
Exemplo
Qual o nome e o código do aluno que efetuou matrícula após o dia "10-01-2008"?
R ß ALUNO (código=codigoaluno) and (Data > 10-01-2008)

MATRÍCULA
RESPOSTA ß p código, nome ( R )
A diferença entre a operação join e o produto cartesiano é que o join efetua apenas as
combinações de tuplas que satisfizerem a condição de junção. No produto cartesiano, todas as
combinações aparecem no resultado, como foi visto anteriormente.
As junções permitem relacionar dados de duas ou mais tabelas de forma que se obtenha
uma única tabela como resultado. Em uma "junção", reconhece-se o select quando há mais de
uma tabela referida na cláusula from. Veja o exemplo a seguir:
Exemplo
SELECT "lista-de-colunas" FROM tabela1, tabela2 WHERE "condição(ões) "

Quando utilizarmos o operador join, e as condições de junções forem apenas de compa-

rações de igualdade, denominamos de equijoin ou inner join. Por exemplo, quando a condição
for a comparação entre o atributo A de uma relação R e o atributo B de uma relação S. Veja o
exemplo a seguir:
Exemplo
SELECT "lista-de-colunas" FROM tabela1, tabela2 WHERE "AtributoA = AtributoB "
Já outro tipo de join, chamado de natural join ou junção natural, é um equijoin, no qual um
dos atributos com valores repetidos (condição de junção) é eliminado.
Operador divisão
A divisão de duas relações R S, em que atributos(S) atributos(R), resulta na relação T
com atributos(T) = {atributos(R) – atributos(S)}, onde, para cada tupla t que aparece no resulta-
do, os valores de t deverão aparecer em R, combinados com cada tupla de S.
R
A a1 a2 a3 a4 a1 a3 a2 a3 a4 a1 a2 a3
B b1 b1 b1 b1 b2 b2 b3 b3 b3 b4 b4 b4
S
A a1 a2 a3
T=R S
B b1 b4
Na maioria das vezes, a divisão é utilizada quando encontramos nas consultas frases do
tipo "para todos".
Exemplo
Obtenha o nome dos alunos que trabalham em todos os projetos em que o aluno Silva
trabalha.
Silva ß s nome = 'silva'(ALUNOS)

ProjSilva ßp codProj (Alocação matrAluno = matr Silva)
ProjAluno ßp codProj, matrAluno (Alocação)
TrabProjSilva ß (ProjAluno ¸ ProjSilva)
Result ßp nome (TrabProjSilva matrAluno = matr Aluno)
Desse modo, você poderá encontrar os nomes dos demais alunos que trabalham nos mes-
mos projetos que o aluno Silva.
© Apêndices 277
Neste Apêndice, você teve a oportunidade de conhecer e aprender os principais conceitos

envolvidos na álgebra relacional, uma linguagem de consulta formal que se baseia em conjuntos
e relações para efetuar operações entre as tabelas do banco de dados.
Para aprimorar o conhecimento em álgebra relacional, é fundamental que você consulte
os livros indicados nas Referências Bibliográficas.


Banco de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

BANCO DE DADOS

CURSOS DE GRADUAÇÃO – EAD

Fazemos parte do Claretiano - Rede de Educação

1. Introdução aos Sistemas de Banco de Dados. 2. Modelo Entidade-Relacionamento.

Corpo Técnico Editorial do Material Didático Mediacional

Claretiano - Centro Universitário

Fazemos parte do Claretiano - Rede de Educação

CADERNO DE REFERÊNCIA DE CONTEÚDO

Unidade 1 – INTRODUÇÃO AOS SISTEMAS DE BANCO DE DADOS

Unidade 2 – MODELAGEM DOS DADOS UTILIZANDO O MODELO ENTIDADE-RELACIONAMENTO

Unidade 3 – MODELO DE DADOS RELACIONAL

Unidade 5 – NORMALIZAÇÃO E DESEMPENHO EM SISTEMA DE BANCO DE DADOS

Unidade 6 – GERENCIAMENTO DE TRANSAÇÕES E CONTROLE DE CONCORRÊNCIA

Unidade 7 – RECUPERAÇÃO DE BANCO DE DADOS E SEGURANÇA 231

Unidade 8 – BANCO DE DADOS DISTRIBUÍDOS

APÊNDICE 1...................................................................................................................................................... 257

2. ORIENTAÇÕES PARA ESTUDO

Claretiano - Centro Universitário

efetuado e, a partir da análise de requisitos, é criado o projeto conceitual, representado pelo

lidade do mapeamento, que expressa o número de entidades relacionadas a outras entidades

Claretiano - Centro Universitário

A função da normalização é atuar como um filtro sobre as entidades e os relacionamentos,

nada; redundâncias de dados desnecessários; perdas acidentais de informação; dificuldade na

Claretiano - Centro Universitário

Claretiano - Centro Universitário

Esquema dos Conceitos-chave

Relacionamento Modelo Relacional

Figura 1 Esquema dos Conceitos-chave de Banco de Dados.

O Esquema dos Conceitos-chave é mais um dos recursos de aprendizagem que vem se

Claretiano - Centro Universitário

Figuras (ilustrações, quadros...)

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE

Figura 1 Banco de Dados.

Banco de dados é um sistema de armazenamento de dados cujo objetivo é registrar e

Claretiano - Centro Universitário

5. DADOS VERSUS INFORMAÇÕES

Claretiano - Centro Universitário

5) Bancos de dados meteorológicos: são aqueles que armazenam informações sobre o

Tabela 1 Tipos de bancos de dados.

** O fornecedor oferece versão específica do SGBD.

Ao analisarmos a Tabela 1, podemos perceber as especificidades que cada produto apre-

6. SISTEMAS DE ARQUIVOS VERSUS SGBDS

Claretiano - Centro Universitário

Figura 2 Sistema de Arquivos.

Arquitetura de sistemas é a forma como o sistema terá os seus componentes organizados

Figura 3 Sistema de Banco de Dados.

7. DADOS EM SGBDS: DESCRIÇÃO E ARMAZENAMENTO

Níveis de Abstração de Dados

Claretiano - Centro Universitário

Um aluno pode pegar até seis

Uma turma limita-se a

Figura 4 Modelos externos de uma instituição acadêmica Sistema de Banco

Na Figura 4, imagine os esquemas externos de duas unidades comerciais corresponden-

Claretiano - Centro Universitário

Create Table PROFESSOR (

Create Table TURMA (

Create Table SALA (

Create Table DISCIPLINA (

um cenário de bancos de dados, um modelo representa estruturas de dados e suas característi-

Claretiano - Centro Universitário

• Relacionamento muitos para muitos (M:N ou *..*): um funcionário pode aprender

Convertendo Regras de Negócio em Modelos de Dados

Tabela 2 Detalhes sobre a evolução dos principais modelos de dados.

• Relacionamento muitos para muitos (M:N ou ..): um funcionário pode aprender