BANCO DE DADOS

E BI
Fundamentos e Conceitos
sobre Banco de Dados
 Sumário
Apresentação. . .................................................................................................................................. 4
Fundamentos e Conceitos sobre Banco de Dados. . .................................................................. 7
1. Fundamentos e Conceitos sobre Banco de Dados................................................................ 7
2. Dados, Informações, Conhecimento e Inteligência............................................................ 10
2.1. Dados.......................................................................................................................................... 11
2.2. Informações. . ............................................................................................................................ 11
2.3. Conhecimento.......................................................................................................................... 11
2.4. Inteligência...............................................................................................................................12
3. Sistemas de Banco de Dados e Sistemas Gerenciadores de Banco de dados (SGBD).12
3.1. As 4 Principais Características que Tornam Vantajosa a Utilização de um SGBD.....16
4. Evolução e Tipos de SGBDs......................................................................................................19
4.1. Modelo em Rede e Modelo Hierárquico: Década de 60...................................................19
4.2. Modelo Relacional: Década de 70. . ......................................................................................21
4.3. Modelo Orientado a Objetos: Década de 80......................................................................21
4.4. Big Data e Modelos NoSQL: Anos 2000..............................................................................21
5. Esquemas e Instâncias do Banco de Dados......................................................................... 26
5.1. Esquema.................................................................................................................................... 26
5.2. Instância................................................................................................................................... 26
6. Arquitetura em Três Esquemas (ANSI/SPARC) e a Independência de Dados............... 29
6.1. Arquitetura em Três Esquemas (ANSI/SPARC)................................................................. 29
6.2. Independência de Dados. . ..................................................................................................... 30
7. Projeto de um Sistema de Banco de Dados...........................................................................31
8. O Ambiente do Sistema de Banco de Dados........................................................................ 33
8.1. Interface com o Usuário........................................................................................................ 35
8.2. Recursos e Componentes Internos.................................................................................... 36
Resumo. ............................................................................................................................................ 37
Mapa Mental................................................................................................................................... 47
Questões de Concurso..................................................................................................................48
Gabarito............................................................................................................................................ 73
 FUNDAMENTOS E CONCEITOS SOBRE
BANCO DE DADOS
1. Fundamentos e Conceitos sobre Banco de Dados
Inicialmente vamos trazer aqui uma reflexão sobre um cenário hipotético, mas que reflete
uma realidade passada e que levou posteriormente ao surgimento do Banco de Dados, por as-
sim dizer, bem como dos Sistemas Gerenciadores de Banco de Dados – SGBDs.
Pense que você está inserido(a) em um contexto de trabalho, numa empresa ou repartição
pública, onde se faz necessário lidar com informações (das mais diversas possíveis) e que tais
informações são produzidas por vários departamentos deste local, cada um especializado em
algo diferente: Vendas, Compras, Gestão de Pessoas e Estoque, por exemplo.
Agora, imagine que cada um destes departamento trabalhe de forma diferenciada, onde
os seus funcionários utilizam diferentes sistemas e aplicações no dia a dia, porém com uma
peculiaridade em comum entre eles: Não há integração ou vinculação entre os dados que são
produzidos por estes sistemas e aplicações, entre os diferentes departamentos.
Diante deste cenário, vamos analisar algumas possibilidades:

Professor, se não há integração ou vinculação entre os departamentos, os dados dos pro-

dutos vendidos são cadastrados a cada venda realizada?
Após realizar compras de produtos, estes produtos ao entrarem no estoque são então
cadastrados novamente?
E se a cada entrada dos dados do produto, seja na compra, na venda ou no estoque, tenha
ocorrido erros de digitação para o mesmo produto em questão?

Ótimas perguntas!!
Bem, todas elas têm praticamente a mesma resposta: Sim, diante do contexto apresenta-
do, existe sim uma grande chance de repetição dos dados do produto nos diferentes sistemas
usados nos departamentos. Isso piora ainda mais quando, por erro humano, dados sobre o
mesmo produto sejam digitados de forma diferente a cada nova operação.

Professor, caso necessite gerar um relatório unificado, onde demonstre o que foi compra-
do, vendido e estoque atual, será possível obter tal informação sem repetições ou erros
de cadastro?

Olha, sinceramente, se todos os problemas relatados de repetição do dado e da possibili-

dade de erros digitação ocorrerem sobre este mesmo dado, este relatório não será dos melho-
res e com certeza apresentará problemas de inconsistência e redundância de dados!
 Agora, imagine, se nesta mesma instituição alguém chega com a ideia de fazer o seguinte:

Vamos fazer uma cópia dos dados de todos os produtos em todos os sistemas, em todos os depar-
tamentos, e desta forma não precisaremos mais ter que digitar os mesmos dados, garantindo que
não ocorrerão mais erros de digitação.

Bem, neste caso, houve uma iniciativa de se resolver o problema da inconsistência, porém
aumentou e muito outro problema, o da redundância de dados e tal redundância gera incon-
sistências, pois diversos usuários estarão ao mesmo tempo inserindo os mesmos dados em
diferentes sistemas. Agora imagine quando um novo produto precise ser cadastrado ou algum
produto existente precise sofrer alterações em suas descrições. Neste caso, todos os siste-
mas terão que receber uma nova carga de dados de produtos ou alterações e isso é muito
improdutivo e arriscado. É o que chamamos de redundância de dados não controlada.

Foi diante de problemas como estes apresentados, ou seja, o da redundância não controla-
da, que surge como solução a utilização dos dados de forma única e sendo acessada por diver-
sos sistemas e consequentemente por diversos usuários. A este conjunto de dados integrados
e que atendem a diversos outros sistemas, é o que podemos chamar de Banco de Dados.
 Então podemos assim definir que o um Banco de Dados é formado por um conjunto de
dados, que estão interrelacionados e que atendem a uma necessidade específica.
Aproveito o momento para apresentar alguns conceitos e definições sobre Banco de Da-
dos, abordados por um autor muito utilizado pelas bancas de concurso, em especial a CESPE/
Cebraspe, vejamos:
Segundo Elmasri & Navathe – Sistema de Banco de Dados, 6ªedição.

Um banco de dados representa algum aspecto do mundo real, às vezes chamado de minimundo. As
mudanças no minimundo são refletidas no banco de dados.
Um banco de dados é projetado, construído e populado com dados para uma finalidade específica.
Ele possui um grupo definido de usuários e algumas aplicações previamente concebidas nas quais
esses usuários estão interessados.

Com base nesta definição do Elmasri & Navathe, vamos então esclarecer alguns dos ter-
mos utilizados pelo autor, o que podemos considerar como propriedades implícitas sobre ban-
co de dados.
A primeira trata-se do termo “minimundo” ou “aspecto do mundo real”, neste ponto o autor
está tentando expressar que toda e qualquer alteração, inclusão ou exclusão feita pelos usuá-
rios nos sistemas que utilizam bancos de dados, estas devem ser refletidas ou armazenadas
assim como estão.
Outro ponto é sobre o fato de o banco de dados ter que atender a uma “finalidade espe-
cífica”, ou seja, deve atender aos interesses e necessidades da organização ou empresa, sob
o viés do negócio praticado. Este uso é feito por pessoas que fazem parte da organização, os
quais são descritos como “grupo definido de usuários” e possuem algum tipo de interesse no
uso destes dados.
Resumindo, um banco de dados não existe ao acaso, ele existe para atender a uma finali-
dade da organização, armazenando dados que refletem esta realidade e que serão utilizados
para diversos fins específicos.
Em outras palavras, um banco de dados (Database) armazenam dados que são deriva-
dos de alguma fonte, onde refletem a interação com determinados eventos do mundo real e
que, neste contexto, existem diversos usuários ou públicos interessados nestes dados. Estes
usuários irão, na maioria das vezes, interagir com estes dados por via de algum sistema ou
aplicação, seja através de uma transação comercial, realização de matrícula em cursos ou até
mesmo em uma consulta na Web.
As mudanças ocorridas no mundo real (ou no “minimundo”, citado por Elmasri & Navathe)
devem ser refletidas no banco de dados, fazendo com que ele seja confiável em todo tempo.
Com base nesta informação, é possível perceber que não há um tamanho limite determinado
para um banco de dados, nem limite na sua composição ou complexidade de dados. Temos
atualmente como exemplo desta infinidade de dados, os sistemas de comércio eletrônico dis-
ponibilizados na internet, onde é possível perceber um catálogo enorme de produtos a se-
rem vendidos, com diversas descrições e formas de consulta, onde após a realização de uma
compra, estes dados passam a ser utilizados para acompanhamento da chegada do produto
em sua casa e também nos e-mails de confirmação e notas fiscais eletrônicas ou físicas, e o
sistema utilizado para esse fim, bem como o banco de dados, devem suportar esta quantidade
enorme de solicitações de compras.
Bem, vamos agora dar uma pequena pausa na evolução do conhecimento sobre banco de
dados, para conhecer às definições e diferenças conceituais do que seja dado, informação,
conhecimento e inteligência.

2. Dados, Informações, Conhecimento e Inteligência

Figura 1: Dados, Informações, Conhecimento e Inteligência

Eu trouxe esta temática agora para fins de esclarecer as diferenças entre cada categoria,
uma vez que na vida prática costumamos lidar com o conhecimento, mas não temos ideia da
origem deste conhecimento e até onde podemos chegar ou aplicar este conhecimento. Sei
que parece meio “filosófico” o que estou falando, mas, por incrível que pareça, tais conceitos
costumam vir em questões de concursos e geralmente tentando confundir o candidato, indu-
zindo ao erro.
Irei aprofundar esse assunto quando chegarmos nas aulas sobre Business Intelligence-BI,
porém como a fonte primária para se chegar até o nível de conhecimento e inteligência é o
dado e estamos falando sobre Banco de Dados, creio ser o momento propício para adentrar-
mos inicialmente neste assunto. Vamos lá?!
 Alguns autores tendem a trabalhar o conceito sobre dado, informação, conhecimento e
inteligência como se fossem sinônimos, porém a grande maioria (incluindo as bancas de con-
cursos) trata cada conceito com suas características próprias, às diferenciando, porém, existe
uma relação entre elas, digamos que evolutiva, vejamos:

2.1. Dados
Podem ser definidos como resultados de eventos do mundo real, onde seu conteúdo é
registrado e armazenado, podendo ser considerado um dado bruto e que fora de um contexto,
por si só, não representa uma informação, mas apenas um dado ou conjunto de dados. Quan-
do os dados são processados, geram informação.

Exemplo: 10/01/2020 é uma data e sozinha representa um dado, mas este dado retrata uma
data de nascimento? uma data de algum evento? ou a data de vencimento de um boleto? Resu-
mindo, ela por si só não consegue informar, ou seja, não gera informação.

2.2. Informações
São definidas em algum contexto e que por sua vez para que produzam informação fa-
zem uso dos dados, que foram processados. Com a produção de informações é possível criar
possibilidade de avaliações e comparações. A informação é algo que passa a fazer sentido
para alguém, para uma empresa ou organização. A partir da informação é possível produzir
interpretação, a partir da leitura humana, por exemplo. A partir do processamento dos dados é
gerada a informação.

Exemplo: Vencimento da Fatura: 10/01/2020. Isto sim é uma informação.

2.3. Conhecimento
Com base no uso das informações é possível colocá-las em ação e assim gerar conheci-
mento. Podemos dizer que o conhecimento tem relação com a capacidade de alguém inter-
pretar e sintetizar um conjunto de informações e associá-las com outros conjuntos de infor-
mações, com base nas experiências, feeling, impressões ou até crenças e daí tirar conclusões
sobre algum assunto ou problema. A construção do conhecimento muitas vezes inclui reflexão
e capacidade de sintetização, sendo inclusive difícil de ser capturada por sistemas de infor-
mação, pois normalmente são mais tácitos do que explícitos. Não são estáticos, pois são
modificados ou transformados a depender da forma como ocorre a interação com o ambiente,
gerando neste momento aprendizado.
 2.4. Inteligência
Quando o conhecimento é encarado como sendo oportunidade, podemos dizer que esta-
mos diante da inteligência, ou seja, a aplicação do conhecimento em um ambiente considera-
do propício, pode gerar vantagem competitiva para uma organização, por exemplo. Podemos
dizer que a inteligência é a base do processo decisório, podendo definir a direção estratégia de
uma organização.

Figura 2: Resumo e evolução do dado ao conhecimento

Bom, após estes esclarecimentos sobre dado, informação, conhecimento e inteligência,

vamos retomar nossa trajetória no conhecimento sobre Banco de Dados.

3. Sistemas de Banco de Dados e Sistemas Gerenciadores de Banco de

dados (SGBD)

Vamos continuar nossa jornada, agora evoluindo o conhecimento de Banco de Dados para
Sistema de Banco de Dados e Sistema Gerenciador de Banco de Dados (SGBD). Diversos au-
tores trabalham com estes conceitos e que são cobrados em provas de concursos, vamos
conhecê-los e diferenciá-los. Para isso vamos utilizar uma figura muito conhecida da literatura
tradicional sobre Sistemas de Banco de Dados, vejamos:
 Figura 3: Elmasri & Navathe – Sistema de Banco de Dados

A figura acima apresenta um diagrama simplificado de um ambiente de sistema de banco

de dados. Nele você pode claramente perceber uma fronteira entre o Sistema de Banco de Da-
dos e o mundo externo, onde nesta parte externa temos os “usuários/programadores”.
O Sistema de Banco de Dados representa a parte interna desta fronteira, onde nela estarão
as aplicações e/ou consultas realizadas, que irão requisitar ao SGBD alguma operação e este
irá então processar e enviar ao Banco de Dados.
Veja abaixo algumas definições sobre SGBD através de alguns autores adotados pelas
bancas de concursos, em especial, a CESPE/Cebraspe:
Segundo Elmasri & Navathe – Sistema de Banco de Dados, 6ªedição:

Um Sistema Gerenciador de Banco de Dados – SGBD é uma coleção de programas que permite aos
usuários criar e manter um banco de dados. O SGBD é um sistema de software de uso geral que
facilita o processo de definição, construção, manipulação e compartilhamento de banco de dados
entre diversos usuários e aplicações.

Segundo C.J. Date – Introdução à Sistema de Banco de Dados:

 O SGBD é o software que trata de todo o acesso ao banco de dados. Um usuário faz um pedido de
acesso usando uma determinada Sublinguagem de dados (geralmente SQL). O SGBD intercepta o
pedido e o analisa. O SGBD, por sua vez, inspeciona o esquema externo (ou as versões objeto desse
esquema) para esse usuário, o mapeamento externo/conceitual correspondente, o esquema concei-
tual, o mapeamento conceitual/interno e a definição do banco de dados armazenado.

Além disso, um SGBD armazena o resultado das especificações dos tipos, estruturas e
restrições de dados. As definições ou informações sobre o banco de dados são armazenadas
no SGBD através do catálogo ou dicionário de dados, também chamado de metadados. Nestes
metadados ficarão registrados os tipos, estruturas e restrições dos dados armazenados.
Quanto à manipulação, um SGBD inclui funções de consultas aos dados armazenados,
bem como para alteração destes dados. Permite também realizar o compartilhamento de seus
dados para diversos usuários e programas, para que haja acesso simultâneo. As operações
sobre os dados, onde ocorrem leituras e gravações são chamadas de transações.
Mas não para por aí, o SGBD também possui funções importantes relacionadas com a pro-
teção do banco de dados e sua manutenção por longo período. Essa proteção inclui proteção
do sistema contra defeitos ou falhas, tanto de hardware, quanto de software, bem como prote-
ção contra acesso não autorizado.

Então, professor, quer dizer que, para que eu possa implementar um banco de dados, eu
preciso obrigatoriamente utilizar um SGBD?

Gostei da pergunta!!
Não necessariamente, pois você poderia por conta própria implementar todos os recursos
já mostrados acima que um SGBD possui, porém seria muito custoso devido à complexidade
envolvida nos requisitos para conseguir alcançar o nível satisfatório. No mercado temos diver-
sos SGBDs, gratuitos e pagos, tem para todos os gostos, como por exemplo: MySQL, Oracle,
SQL Server, dentre outros.
Creio que chegou o momento de mostrar um exemplo do uso do banco dados, através da
representação de algumas tabelas contendo diversos dados, sendo que estas tabelas (rela-
ções) mantêm algum tipo de relacionamento entre elas e será possível perceber inicialmente
através dos nomes dos campos envolvidos.
 Figura 4: Elmasri & Navathe – Tabelas do BD Universidade

A figura acima apresenta um conjunto de tabelas (relações), como exemplo de um banco

de dados de uma universidade, onde será possível armazenar dados referentes ao ALUNO e
seu HISTÓRICO ESCOLAR, porém, para que seja possível formar um histórico escolar, se faz
necessário que o aluno esteja vinculado a uma ou mais TURMAS, sendo que nas turmas ne-
cessitam dos dados das DISCIPLINAS e algumas disciplinas possuem PRÉ-REQUISITOS de
outras disciplinas para que possam ser cursadas.
Perceba que algumas tabelas possuem dados que são de outras tabelas, para que se man-
tenha um vínculo entre elas, reproduzindo a semântica das regras aplicadas pela universidade,
como por exemplo, a coluna Numero_disciplina está presente na tabela TURMA e na tabela
DISCIPLINA formando assim um relacionamento. Outro exemplo é o da coluna Identificacao_
turma e Numero_aluno que estão presentes na tabela HISTORICO_ESCOLAR e nas tabelas
TURMA e ALUNO respectivamente, formando então outros relacionamentos.
Todas estas tabelas estão fisicamente no banco de dados na forma de arquivos, em cada
tabela, ao ser criada, são definidos os tipos de dados de cada coluna (atributos). Quando uma
linha da tabela é preenchida, dizemos temos ali um registro, por exemplo, na figura acima na
tabela ALUNO, temos o primeiro registro com os seguintes dados: Silva,17,1,CC, que corres-
pondem às colunas Nome, Numero_aluno, Tipo_aluno e Curso, respectivamente.

PEGADINHA DA BANCA
Cuidado ao ler as assertivas e não deixar “passar batido” o seguinte: TABELA é o mesmo que
RELAÇÃO e a VINCULAÇÃO de uma tabela com outra tabela forma um RELACIONAMENTO.

Quanto aos relacionamentos entre as tabelas e como serão construídos, veremos mais
adiante quando formos estudar modelagem de dados durante nossas aulas, assim como tam-
bém a linguagem para se realizar consultas, inclusões, alterações e exclusões de dados, como
também operações nas estruturas de dados, podendo inserir, alterar e excluir tabelas, utilizan-
do a linguagem SQL (Structured Query Language) em suas diferentes categorias.
Para finalizar esta etapa da aula onde estamos conhecendo às características de um SGBD,
vamos continuar a perseguir o que o autor querido pela CESPE/Cebraspe (Elmasri & Navathe)
fala sobre as vantagens da utilização de dados numa abordagem por uso de banco de dados,
ao invés de arquivos de dados separados em diferentes departamentos, como vimos no iní-
cio da aula.

3.1. As 4 Principais Características que Tornam Vantajosa a Utilização

de um SGBD

3.1.1. Natureza de Autodescrição de um Sistema de Banco de Dados

Como vimos anteriormente, o SGBD além de possuir um banco de dados onde irão ser ar-
mazenados os dados, também possui um catálogo de dados. Esse catálogo armazenará toda
estrutura do arquivo da base dados e isso inclui as tabelas, ou seja, toda definição das colunas
e seus tipos de dados, além de restrições e relacionamentos e outros itens que façam parte
da estrutura.
O SGBD é feito para ser abrangente e não específico para uma aplicação desenvolvida
pelo programador, ou seja, ele é feito para trabalhar de forma satisfatória com qualquer quan-
tidade de aplicações de banco de dados.

3.1.2. Isolamento entre Programas e Dados, e Abstração de Dados

Como vimos no início da aula, quando falamos de uma organização utilizando dados repli-
cados em diferentes sistemas e departamentos, tal cenário se torna arriscado e improdutivo
quando surge a necessidade de novas atualizações de dados ou até da estrutura do dados
(novas tabelas, mudanças nos tipos das colunas, dentre outras).
Ao utilizar um SGBD, esta estrutura é armazenada no catálogo de forma separada das
aplicações que os acessam, ou seja, de forma independente ou isolada, é o que chamados de
independência de dados do programa.
 Cada estrutura criada e armazenada no catálogo apresenta sua abstração relacionada
com um modelo específico, ou seja, a depender do “minimundo” que se quer satisfazer, por
exemplo, a estrutura da tabela ALUNO é diferente da estrutura da tabela DISCIPLINA. As es-
truturas das tabelas que formam o sistema para UNIVERSIDADE são diferentes, por exemplo,
das tabelas que sirvam para um sistema voltado para VENDAS ON-LINE, porém ambos podem
estar no mesmo SGBD, em bancos de dados diferentes.

3.1.3. Suporte para Múltiplas Visões de Dados

Em decorrência das vantagens da capacidade de abstração e isolamento, e por saber que

diversos usuários estarão direta ou indiretamente utilizando a mesma base de dados, seja por
meio de uma aplicação ou até no SGBD usando linguagem SQL, se faz necessário que seja
possível obter os dados armazenados sob diversas perspectivas, ou seja, um usuário do siste-
ma de UNIVERSIDADE pode requerer um relatório onde queira ver os dados de histórico escolar
agrupados por alunos, por exemplo, enquanto outro usuário queira ver, de forma agrupada, a
lista de disciplinas com suas respectivas dependências de pré-requisitos.
Resumindo, o SGBD permite essa capacidade de se obter várias visões sobre os dados
armazenados, bem como também dados transformados ou derivados, ou seja, é possível além
dos agrupamentos, realizar cálculos, contagens, dentre outras possibilidades que iremos co-
nhecer quando estudarmos a linguagem SQL.

3.1.4. Compartilhamento de Dados e Processamento de Transação Multiu-

suário

Já vimos durante a aula que o SGBD é acessado de forma simultânea e concorrente por
diversos usuários e aplicações, e neste momento cada operação feita por diferentes usuários
forma uma transação.
Com vistas a garantir o melhor resultado para o usuário ou aplicação, o SGBD precisa in-
cluir um software de controle de concorrência para que diferentes usuários que acessem um
mesmo dado, ao mesmo tempo, possam fazer isso de forma controlada.
Segundo Elmasri & Navathe:

Podemos dizer que uma transação é um programa em execução ou processo que inclui um ou mais
acessos ao banco de dados, seja para leitura ou atualização de seus registros, sendo executada de
forma completa e sem interferências de outras transações.

Exemplo tradicional no controle de concorrência de diferentes transações está na comerciali-

zação de passagens aéreas. Neste cenário, a aplicação, por exemplo, na escolha do assento
do passageiro precisa garantir o isolamento da transação para fins de evitar problemas na
reserva de um mesmo assento para diferentes passageiros e isso é feito utilizando recursos
de controle de transação que existem no SGBD.
 Figura 5: 4 principais características do SGBD

Um conceito muito importante a ser tratado no tocante a transação é que se faz necessário
garantir às propriedades do ACID. E o que é isso professor? Eu explico!
ACID é o acrônimo de: Atomicidade, Consistência, Isolamento e Durabilidade. Vejamos o que
significa cada uma destas propriedades:
Atomicidade: É a propriedade que garante que a transação seja tratada de forma única, a qual
deve ser executada por completo ou em caso de falha, que seja falha por completo, não deixan-
do partes das operações sendo executadas com sucesso e outras fiquem pendentes, causan-
do inconsistências futuras nos dados. Resumindo, é a regra do “tudo ou nada”, se a transação
falhar no meio, tudo deve voltar ao estado original, assim se espera. Esse retorno é chamado
de Rollback.
Consistência: Deve garantir que a transação leve o banco de dados de um estado válido para
outro estado também válido, mantendo a estabilidade do banco de dados. Essa estabilidade
está relacionada com a garantia de que os dados a serem registrados sejam válidos de acordo
com as regras de relacionamento definidas. Um exemplo, seria se uma transação tentasse
incluir na tabela de TURMA um Numero_disciplina que não exista na tabela DISCIPLINA, neste
caso a transação falhará, garantindo a consistência do banco de dados.
Isolamento: É a propriedade que irá garantir que durante transações, o acesso simultâneo a
um mesmo dado seja tratado como se fosse sequencial, garantindo que uma transação não
seja afetada por outra transação concorrente, sem que haja falha percebida pelo usuário ou
aplicação. Por exemplo, no caso tratado anteriormente sobre reserva de assento na compra de
passagens aéreas, em caso de transações simultâneas de tentativa de reserva sobre um mes-
mo assento por diferentes usuários, o primeiro usuário que concluir a transação da reserva,
garantirá o registro na base de dados da reserva em seu nome e a transação do outro usuário
então será interrompida, voltando ao seu estado de origem, ou seja, sofrerá um Rollback.
Durabilidade: É propriedade que o SGBD deve ter de que uma transação já executada (efetiva-
da), permaneça neste estado mesmo havendo algum problema de falha no sistema ou algum
travamento em sistema operacional ou até mesmo queda de energia. Isso é garantido através
da gravação (persistência) das transações em disco ou dispositivos não voláteis, ficando en-
tão disponível quando o banco de dados for reinicializado.

Figura 6: Propriedades do ACID

4. Evolução e Tipos de SGBDs

Esse conhecimento é muito importante para às provas de concursos, pois é comum vir
questões que apresentem diferentes tipos de SGBDs tentando confundir o candidato quanto à
algumas características existentes, seja na comparação entre SGBDs ou mesmo nos concei-
tos ou capacidades de cada um. Vem comigo, vamos viajar no tempo!

4.1. Modelo em Rede e Modelo Hierárquico: Década de 60

Em ambos os modelos o acesso se dava por operações de ponteiros, unindo os registros
de dados por meio de links. Além disso o detalhe da estrutura de armazenamento dependia
do tipo de dado que fosse ser armazenado e para que os usuários pudessem realizar alguma
consulta seria necessário conhecer a estrutura física do banco de dados. Outro ponto em
comum é a ênfase dada aos registros que serão processados ao invés do foco ser na estru-
tura global.
O modelo de dados hierárquico foi o primeiro modelo de dados a ser reconhecido. Nesse
modelo de dados, os dados são estruturados formando hierarquias, semelhantes a uma ár-
vore, sendo que cada nó desta hierarquia possui ocorrências de registros, sendo cada registro
uma coleção de campos (ou atributos), onde cada um contém um dado. O registro-pai é o re-
gistro que precede outros, sendo estes outros registros-filhos. Um registro pode ser associado
a vários registros diferentes, desde que seja replicado, porém isso caracteriza uma grande
desvantagem deste modelo, pois pode causar inconsistências de dados quando houver atua-
lizações gerando, de forma desperdiçável, a ocupação de espaço em disco.

Figura 7: C.J. Date – Modelo Hierárquico

O modelo de dados em rede surgiu como uma extensão do modelo de dados hierárquico,
as relações de dados (tabelas) eram representadas por grafos bidirecionais, formando um úni-
co tipo de associação, bem como formando relacionamentos entre às relações do tipo muitos-
-muitos (veremos mais sobre os tipos de relacionamentos na próxima aula). O diagrama para
representar os conceitos do modelo em redes consiste em dois componentes básicos: Caixas,
que correspondem aos registros e Linhas, que correspondem às associações.
 4.2. Modelo Relacional: Década de 70
Os modelos anteriores se demonstram ser inflexíveis, principalmente na questão de re-
organização dos dados ou quando se adicionavam novas aplicações. Foi neste cenário que
surgiu o Modelo Relacional, satisfazendo a uma série de necessidades, como:
• Criação do catálogo de dados independente de estrutura para representação física dos
dados;
• Utilização de linguagem de alto nível e estruturada (SQL);
• Independência entre dados e programas;
• Representação de dados de um lado e estrutura física do outro;

O exemplo apresentado do banco de dados de uma UNIVERSIDADE representa um modelo

relacional.

4.3. Modelo Orientado a Objetos: Década de 80

Os bancos de dados relacional apesar de se mostrarem satisfatórios, traziam algum limite
no tocante a representação semântica dos dados, principalmente nos tipos de dados. Essa
necessidade por conta da complexidade exigida pelo mercado em algumas áreas fez surgir os
Modelo Orientado a Objetos, cuja principal característica é que além de armazenar dados, ele
também contém métodos que definem comportamentos sobre os dados armazenados.

4.4. Big Data e Modelos NoSQL: Anos 2000

Apesar do surgimento do modelo orientado a objetos, o consumo dos SGBDs no modelo
relacional continuou crescendo e com a chegada da internet e aumento do uso de dispositivos
móveis, bem como da utilização de redes sociais, o mundo inteiro passou a lidar com os dados
não somente de forma estruturada, mas também no formato semiestruturado e não estrutu-
rado ou seja, os dados não estavam obrigatoriamente presentes em tabelas com colunas e
linhas, os dados passaram a ser enxergados a partir de um “joinha” na rede social, na “curtida”,
nos emojis, assim também como nos textos de comentários, enfim, o modelo relacional não
mais suportaria estas mudanças porque o “céu passou a ser limite” com relação aos tipos de
dados e estruturas de dados.
Foi neste cenário que surgiu o termo Big Data e com ele os bancos de dados NoSQL (Not
Only SQL). Os bancos de dados NoSQL proporcionam armazenamento de dados estruturados
e semiestruturados (como arquivos JSON, XML, por exemplo) o que foi o meio de lidar com os
5 Vs do Big Data, tratados por diversos autores como:
• Volume: É o primeiro desafio que as organizações enfrentam ao lidar com Big Data. Cor-
responde à quantidade de dados armazenados, representados através do tamanho e da
quantidade de registros/informações que um banco de dados possui. Quanto maior o
volume, maiores os esforços na gestão de dados;
 • Velocidade: É o desafio de lidar com o tempo rápido de resposta com que os novos da-
dos são criados e os dados existentes, modificados. Esses dados devem estar disponí-
veis imediatamente para operações de pesquisa e análise dos dados. Está relacionado
com o alto fluxo de entrada de dados, levando em consideração a sua variedade;
• Variedade: Consiste nas implementações de dados que requerem tratamento de vários
formatos e tipos, incluindo dados estruturados e não estruturados. Os bancos de dados
devem ser capazes de analisar todos estes tipos de dados para produzir resultados de
pesquisa e análise que não poderiam ser alcançados anteriormente;
• Veracidade: Consiste no grau de incerteza e inconsistência dos dados devido às ambi-
guidades, à baixa qualidade e a completeza dos dados. Está relacionado com a confian-
ça no dado;
• Valor: Corresponde ao valor financeiro ou não, que um determinado conjunto de dados
fornece à organização. Só fará sentido o investimento em Big Data, se o valor da análise
dos dados compensar o custo de sua coleta, armazenamento e processamento.

É possível classificar os diferentes modelos em NoSQL de acordo com as diferentes estru-

turas de armazenamento de cada um, são eles:

4.4.1. Modelo Orientado a Chave-Valor

Estrutura mais simples dos bancos NoSQL.

A chave geralmente é do tipo String, já o valor pode ser qualquer tipo.
Usado tanto para persistir dados, quanto para ficar em memória formando caches.
Adequado para aplicações de leituras frequentes.
Pesquisa em banco fica limitada ao campo chave, não podendo fazer consultas mais
elaboradas.
Ideal para resolver questões de lentidão para leitura e escrita de dados em grande varieda-
de e volume.
Limitação: Campo valor não permite indexação.
Pode armazenar documentos e imagens.
Exemplos de bancos de dados orientados a chave-valor:
– DynamoDB;
– Redis;
– Riak;
– Memcached.

4.4.2. Modelo Orientado a Documentos

É uma extensão do modelo chave-valor, onde o valor é o próprio documento.

Pode criar índices sobre os dados armazenados.
Pode realizar vários tipos de consultas e filtros nos valores armazenados e não somente
no campo chave.
Os documentos podem ser formados por dados semiestruturados, como XML e JSON.
Indicado para armazenamento de páginas Web e catalogação de documentos.

Exemplos de bancos de dados orientados a documentos:

– Couchbase;
– CouchDB;
– MarkLogic;
– MongoDB.

4.4.3. Modelo Orientado a Colunas

É uma extensão do modelo chave-valor, porém apresenta algumas características do mo-

delo de banco relacional (criação de linhas e colunas).
Busca resolver problemas de flexibilidade e escalabilidade no armazenamento de dados.
No tocante a flexibilidade, ao invés de previamente definir as colunas, serão responsáveis por
armazenar registros. O responsável pela modelagem cria “famílias de colunas”, sendo estas fa-
mílias agrupadas de acordo com a frequência de dados utilizadas nas aplicações. O resultado
é que cada registro vai receber as colunas que de fato foram utilizadas, sem precisar alterar a
estrutura de dados (esquema) já armazenados. Vejamos abaixo um exemplo:
 Figura 10: NoSQL – Modelo Orientado a Colunas

É possível perceber na figura acima que o ID_1 (Joao) utiliza famílias de dados diferentes
em relação a ao ID_2 (Jose) em preferencia_livros, por exemplo. E em dados_cadastrais, cada
um dos IDs utilizam diferentes famílias.
Cada registro pode ter quantidade de colunas diferentes. Isso é possível pelo fato de
que os dados são armazenados fisicamente em uma sequência orientada por colunas e não
por linhas.
Solução adequada para casos em que:
• Exista grande volume de dados;
• Necessite de alto desempenho e disponibilidade na leitura e escrita de dados;
• Inclusão de campos dinâmicos garantindo a disponibilidade;
• É utilizado por aplicações de larga escala, como por exemplo, o serviço de mensagens
do Facebook.

Exemplos de bancos de dados orientados a colunas:

– Accumulo;
– Cassandra (o mais popular no mercado);
– HBase;
– Hypertable.
 4.4.4. Modelo Orientado a Grafos

Quando a estratégia requer saber mais do relacionamento dos dados, do que sobre o
próprio dado.
Em comparação com os demais modelos, o orientado a grafos é o mais especializado.
Totalmente modelado utilizando a teoria dos grafos, ou seja, possui um modelo de da-
dos estabelecido, utilizando vértices e arestas para armazenar dados dos itens que passaram
pela coleta.
Ao estabelecer o vínculo entre os dados, é possível definir este tipo de vínculo, criando ró-
tulos de acordo com o negócio.
É formado por uma coleção de nós e arestas. Cada nó representa uma entidade (por ser
uma pessoa, organização, local) e cada aresta representa uma conexão ou relacionamento
entre dois nós. Cada nó em um banco de dados baseado em grafos é definido por um identi-
ficador exclusivo, um conjunto de arestas de saída e/ou arestas de entrada e um conjunto de
propriedades expressas como pares de chave/valor.
Vejamos um exemplo:

Figura 11: NoSQL – Modelo Orientado a Grafos

Exemplos de bancos de dados orientados a grafos:

– AllegroGraph;
– ArangoDB;
– InfoGrid;
– Neo4J (o melhor, em minha opinião)
– Titan.
5. Esquemas e Instâncias do Banco de Dados
Bem, estamos caminhando para o final da parte teórica da aula, porém sempre tem algo
importante para tratar a fim de dar completude ao seu conhecimento para fins de aumentar
sua capacidade competitiva na resolução de questões e consequentemente nas provas. Mas,
não perca o ritmo, vamos lá!
Até aqui passamos por várias explicações sobre banco de dados, sistema gerenciador
de banco de dados, características, vantagens e desvantagens, dentre outros aspectos, mas,
como é que um banco de dados está disponível para uso?
Eu explico. Para isso se faz necessário, inicialmente, distinguir o que é a descrição do ban-
co de dados e o próprio banco de dados.

5.1. Esquema
A descrição do banco de dados é o que chamamos de esquema (Schema). Durante nossa
aula falamos várias vezes de um componente importante em um SGBD, o chamado catálogo
de dados. Como já vimos, o catálogo de dados guarda informações sobre as definições das
relações(tabelas) e dos relacionamentos (vínculo entre as tabelas), onde várias propriedades
são definidas como, por exemplo: os tipos e tamanhos das colunas (atributos), quais desses
atributos serão utilizados nos relacionamentos entre tabelas, ou seja, a definição das chaves
primárias e chaves estrangeiras, bem como também regras de restrições, ou seja, a definição
da obrigatoriedade ou não do preenchimento de determinado atributo. Este conjunto de defi-
nições, que fazem parte do catálogo, são também chamados de metadados, e sempre que o
SGBD precise recorrer aos dados estruturais, os metadados serão lidos no catálogo.
O esquema do banco de dados é definido durante a fase de projeto do banco de dados
e não muda com muita frequência, o que na verdade muda constantemente são dados que
serão utilizados no banco de dados, ou seja, o seu conteúdo. Estes dados são inseridos, altera-
dos, excluídos durante todo tempo, a depender da frequência de uso do banco de dados pelas
aplicações ou diretamente pelos usuários, como desenvolvedores/programadores.

5.2. Instância
Como é possível perceber, os dados reais armazenados em um banco de dados podem
mudar a todo tempo e estes dados em determinado momento no tempo são chamados de
estado ou de instante do banco de dados, ou instância do banco de dados.
Então, resumindo, quando um novo banco de dados é definido, especificamos seu esque-
ma apenas para o SGBD e neste momento, o estado do banco de dados é vazio, ou seja, temos
ali apenas um “esqueleto” ou estrutura do banco de dados, porém, quando este banco de dados é
posto em uso, ou seja, quando ele é carregado (ou populado) obtendo ali dados iniciais, então
estamos diante de uma instância do banco de dados, ou seja, na instância os dados utilizam
o esquema. Vejamos abaixo um exemplo de catálogo, esquema e instância, com base no mo-
delo de UNIVERSIDADE.

Figura 12: Catálogo, Esquema e Instância

Antes de entrarmos no tópico seguinte da aula, desejo que você tenha em mente que os
usuários responsáveis por projetar um banco de dados para uma aplicação, sendo essa aplica-
ção a ferramenta que irá contribuir para que os negócios ou necessidades de uma organização
sejam satisfeitos, elaboram inicialmente um modelo de dados que seja abstrato, ocultando
detalhes do armazenamento inicialmente, mas que servirá para descrever a estrutura deste
banco dados.
Para que seja possível construir a estrutura do esquema do banco de dados, o modelo
definido deve apresentar um conjunto de conceitos que englobem: descrição dos dados,
relacionamentos entre estes dados, semântica dos dados e regras de restrições para manter
a consistência dos dados.
Com base nessa linha de raciocínio, os modelos de dados percorrem a trajetória a partir do
modelo conceitual (também chamado de alto nível), passando pelo modelo representacional
de forma intermediária, chegando no modelo físico (também chamado de baixo nível). Essa
trajetória basicamente sai do nível mais próximo do usuário final, terminando no nível mais
próximo da estrutura de arquivos do banco de dados.
Finalizando este tópico, trago abaixo algumas definições de um trio de autores também
muito utilizado pelas bancas de concursos (Silberschatz-Korth-Sudarshan), onde eles definem
os níveis de abstração dos modelos de dados em: Nível Físico, Nível Lógico e Nível de Vi-
são (view).
Segundo (Silberschatz-Korth-Sudarshan), grifo nosso:

Nível Físico: O nível de abstração mais baixo descreve como os dados são realmente armazenados.
O nível físico descreve em detalhes estruturas de dados complexas de baixo nível.
Nível Lógico: O próximo nível de abstração mais alto descreve que dados estão armazenados no
banco de dados e que relacionamentos existem entre eles. O nível lógico, portanto, descreve o ban-
co de dados inteiro em termos de um pequeno número de estruturas relativamente simples. Embora
a implementação das estruturas simples no nível lógico possa envolver estruturas em nível físico
complexas, o usuário do nível lógico não precisa estar consciente dessa complexidade. Os adminis-
tradores de banco de dados, que precisam decidir que informações armazenar no banco de dados,
usam o nível lógico de abstração.
Nível de view: O nível de abstração mais alto descreve apenas parte do banco de dados. Mesmo
que o nível lógico use estruturas mais simples, a complexidade permanece devido à variedade de
informações armazenadas em um grande banco de dados. Muitos usuários do sistema de banco
de dados não precisam de toda essa informação: em vez disso, eles precisam acessar apenas uma
parte do banco de dados. O nível de view existe para simplificar sua interação com o sistema. O
sistema pode fornecer muitas visões para o mesmo banco de dados.

Figura 13: Modelo em 3 níveis

6. Arquitetura em Três Esquemas (ANSI/SPARC) e a Independência de
Dados
Durante esta aula vimos 4 principais características que tornam vantajosa a utilização
de um SGBD:
• 1. Natureza de autodescrição de um sistema de banco de dados;
• 2. Isolamento entre programas e dados, e abstração de dados;
• 3. Suporte para múltiplas visões de dados;
• 4. Compartilhamento de dados e processamento de transação multiusuário.

Foi com base nestas características acima que surgiu uma proposta de arquitetura para
fins de facilitar a sua visualização, chamada de arquitetura em três esquemas.

6.1. Arquitetura em Três Esquemas (ANSI/SPARC)

O grande objetivo desta arquitetura é mostrar a separação entre as aplicações do usuário
e do banco de dados físico. Para melhor explicar eu trago uma figura muito conhecida nos es-
tudos sobre banco de dados e seus conceitos frequentes nas provas de concursos, vejamos:

Figura 14: Elmasri & Navathe – Arquitetura em 3 esquemas

Nível Externo: Está mais próximo do usuário e longe dos aspectos físicos do banco de
dados, onde o interesse e necessidade do usuário ou da organização se faz presente através
de um modelo de dados representativo, é o que chamamos também de modelo de dados de
alto nível.
Nível Conceitual: A partir da visão externa do usuário em relação ao banco de dados, é pos-
sível agora construir um esquema conceitual destes dados. O esquema conceitual irá, neste
momento, ocultar os detalhes das estruturas de armazenamento físico e foca na descrição
representativa das entidades, tipos de dados, relacionamentos, restrições e operações dos
usuários. A construção deste esquema conceitual toma por base o modelo de dados de alto
nível, presente no nível externo.
Nível Interno: Agora sim, chegamos na camada mais próxima dos dados armazenados, ou
seja, o esquema interno, onde a descrição do armazenamento físico é descrita. Neste esque-
ma todos os detalhes sobre o armazenamento e caminhos de acesso, são detalhados.
É necessário observar que os três esquemas são apenas descrições dos dados. Os da-
dos de fato armazenados estão em nível físico. Quando grupos de usuários fazem uso de um
SGBD baseado em arquitetura de três esquemas, eles farão uso do esquema externo que foi
estabelecido, ou seja, os usuários que fazem parte do universo de dados do sistema UNIVE-
SITÁRIO, por exemplo, terão acesso ao esquema conceitual estabelecido para este universo,
já os usuários de um outro esquema, por exemplo, de um sistema de VENDAS, estes usarão o
seu esquema estabelecido.

Mas professor, então quer dizer que será preciso ter um SGBD para cada um destes uni-
versos de sistema, ou seja, um SGBD para o sistema UNIVERSITÁRIO e outro para o de
VENDAS?

Ótima pergunta e eu explico!

A resposta é não! É possível utilizar um único SGBD para diferentes bancos de dados (em
esquemas diferentes), porém ele transformará uma solicitação (requisição), que foi especifi-
cada em um esquema externo, para uma solicitação no esquema conceitual e por fim numa
solicitação de esquema interno para então ocorrer o processamento no banco de dados arma-
zenado. Esses processos de transformação de requisições e os resultados obtidos entre os di-
ferentes níveis são chamados de mapeamentos. A depender do volume esperado e do tamanho
do banco de dados, estes mapeamentos podem ser custosos em tempo de processamento.

6.2. Independência de Dados

Agora, para finalizar este tópico da aula, vamos conhecer duas definições importantes que
retratam a independência dos dados, com base na arquitetura três esquemas vista acima.
Segundo Elmasri & Navathe, autor querido da banca Cespe/CEBRASPE, a independência
dos dados pode ser dividida em dois tipos, grifo nosso:

Independência Lógica de Dados: É a capacidade de alterar o esquema conceitual sem ter de alterar
os esquemas externos ou os programas da aplicação. Podemos alterar o esquema conceitual para
 expandir o banco de dados (acrescentando um tipo de registro ou item de dado), para alterar restri-
ções ou para reduzir o banco de dados (removendo um tipo de registro ou item de dado).
Independência Física de Dados: É a capacidade de alterar o esquema interno sem ter de alterar o
esquema conceitual. Logo, os esquemas externos também não precisam ser alterados. Mudanças
nos esquemas internos podem ser necessárias porque alguns arquivos físicos foram reorganizados
– por exemplo, ao criar estruturas de acesso adicionais – para melhorar o desempenho da recupe-
ração ou atualização.

O que o autor nos apresenta de relevante com relação ao uso do SGBDs é a capacidade de
se realizar alterações em um nível, sem afetar o outro, ou seja, de poder realizar alterações em
um nível mais baixo sem que haja impacto no nível conceitual e vice-versa.
Apesar desta afirmação, existe uma ressalva apontada pelo mesmo autor, no tocante a não
obrigatoriedade da existência de independência lógica, vejamos o que ele diz:

... Em geral, a independência física de dados existe na maioria dos bancos de dados e ambientes
de arquivo, nos quais detalhes físicos, como a localização exata dos dados no disco, e detalhes
de hardware sobre codificação do armazenamento, posicionamento, compactação, divisão, mes-
clagem de registros, e assim por diante, são ocultados do usuário. As demais aplicações ignoram
esses detalhes. Por sua vez, a independência lógica de dados é mais difícil de ser alcançada porque
permite alterações estruturais e de restrição sem afetar os programas de aplicação – um requisito
muito mais estrito. (Navathe – Sistemas de Banco de Dados – 6ª. Ed.)

7. Projeto de um Sistema de Banco de Dados

Trago agora uma figura que mostra, de forma resumida, as etapas para se desenvolver o
projeto de um sistema de banco de dados.
Esta figura “fala por mil palavras”, nela podemos resumir nossa aula, até aqui, em vários
aspectos. Numa primeira leitura, você percebe claramente que há uma fronteira entre o que
independe do SGBD e do que é específico do SGBD, e o que define esta fronteira é o Projeto
Lógico, onde há o mapeamento do modelo de dados, ou seja, as definições do modelo con-
ceitual, em conjunto com a análise funcional, contribuem para criação do projeto físico do
banco de dados.
 Figura 15: Elmasri & Navathe – Projeto de um Banco de Dados

No Levantamento e Análise de Requisitos, que independe do SGBD, podem ser aplicadas

técnicas de engenharia de software que facilitam a comunicação entre diferentes especialis-
tas da área de tecnologia da informação e área de negócio, sendo considerada uma fase es-
sencial para o desenvolvimento da solução, pois a sua qualidade está intimamente relacionada
a um documento de requisitos preciso.
No Projeto Conceitual, que também independe de SGBD, tem como resultado a construção
de um modelo conceitual, que será representado por um diagrama entidade relacionamento
(veremos nas próximas aulas sobre modelagem de dados). Nesta etapa podem ainda surgir
questões sobre os requisitos, sendo recomendável questionar o especialista da área de negócio
sobre tais dúvidas. Sendo assim, você verifica que o modelo conceitual pode auxiliar no refina-
mento dos requisitos da solução.
O Projeto Lógico tem por objetivo transformar o modelo conceitual em um modelo lógi-
co, definindo como o banco de dados será implementado em um SGBD específico. Quando
falamos em um SGBD específico, podemos estar falando por exemplo em alguns SGBDs de
mercado, como MySQL, PostgreSQL, Oracle, SQLServer, dentre outros.
O Projeto Físico nesta etapa o modelo do banco de dados é enriquecido com detalhes que
influenciam no seu desempenho, como definições de índices e consultas, por exemplo.

8. O Ambiente do Sistema de Banco de Dados

Até o momento você conseguiu visualizar conceitos, características e alguns princípios
que envolvem a utilização de um banco de dados, bem como ele é implementado em um
sistema de banco de dados e gerenciado por um SGBD, o qual é formado por um conjunto
complexo de componentes e softwares e que é muito importante conhece-los pelo seguinte
motivo: As bancas de concurso vão tentar confundir você através das trocas de conceitos e
funcionalidades que cada um destes componentes desempenha.
Então, vamos usar, uma figura muito conhecida como referência para às explicações
seguintes.
 Figura 16: Elmasri & Navathe – Ambiente do Sistema de Banco de Dados

A figura acima apresenta uma separação em dois quadros: o primeiro (parte superior da
figura) apresenta os vários usuários do banco de dados e como eles se comunicam com a
segunda parte da figura (parte inferior), onde é possível ver os detalhes internos de um SGBD,
onde verifica-se os locais de armazenamento, processamento da consulta e controle de tran-
sações, por exemplo.
 8.1. Interface com o Usuário
Trata-se da parte superior da figura, onde é possível observar da esquerda para direita algu-
mas categorias de usuários: DBAs, Usuários Casuais, Programadores de Aplicação e Usuários
Paramétricos.
Os DBAs são os Administradores de Banco de Dados (Data Base Administrator), iremos
estudar mais sobre suas atividades na aula sobre Administração de Banco de Dados, mas de
forma resumida, nesta figura ele executa atividades de criação da estrutura de um banco de
dados através da linguagem DDL (Data Definition Language), uma das categorias da linguagem
SQL, que vamos estudar em aulas posteriores. Os DBAs utilizam interfaces interativas, onde é
possível informar os comandos DDL e ele é compilado e executado. Por fim irá refletir no catá-
logo do sistema onde ficam armazenados todas as estruturas dos esquemas(metadados) dos
bancos de dados. Ele pode criar um banco de dados, novas tabelas e atributos, também podem
alterar a estrutura das que já existem, dentre outras atividades. Também podem executar co-
mandos com mais privilégios do que um usuário comum, como por exemplo, podem inserir um
lote de registros em uma determinada tabela via comandos SQL, neste caso o comando será
processado e executado com destino na instancia do banco de dados em uso no momento.
Os programadores de aplicação fazem parte de outra categoria de usuários, um pouco
parecida com o DBA no sentido de podem executar comandos SQL, porém, normalmente na
categoria DML (Data Manipulation Language) que são comandos para manipulação de dados
e não criação, alteração ou exclusão de estruturas. Podem inserir, consultar e alterar dados de
acordo com a necessidade do desenvolvimento da aplicação. As aplicações desenvolvidas
por estes programadores também realizam operações de manipulação de dados no banco de
dados, geralmente estão junto com o código desenvolvido e dali é feita uma chamada ao ban-
co de dados através da linguagem SQL, nas categorias DQL (Data Query Language), utilizada
apenas para consulta e DML. Perceba, pela figura, que a todo o tempo o catálogo de sistema é
consultado e depois autorizado o processamento das instruções. Os programadores também
podem executar comandos que possam atuar em dados que estejam também sendo utiliza-
dos por outros usuários, o que irá requerer o controle de concorrência através da utilização de
transações. Essas transações são executadas pelos usuários paramétricos (abstração usada
pelo autor da figura), sendo considerada cada transação como sendo uma execução separada
(isolamento).
Os usuários casuais, são os usuários do dia a dia, que utilizam aplicações já desenvolvidas
por alguma empresa ou algum programador/desenvolvedor. São usuários não dispõem de in-
terfaces para executar comandos SQL e na maioria deles não possuem conhecimento técnico
para tal, porém, independente disso, as aplicações que eles utilizam realizam consultas e co-
mandos de manipulação de dados e consequentemente, estes comandos, passam pelo fluxo
que envolve a compilação do comando, consulta ao catálogo e posterior processamento da
requisição feita.
 As consultas aos dados via comando, são analisadas pelo compilador da consulta, pas-
sando para uma linguagem de uso interno do SGBD. Essa consulta pode passar por uma oti-
mização a depender de como ela foi escrita, pois pode ser ordenada, pode ter redundâncias
eliminadas e utilizar índices que ajudarão a melhorar a performance e o tempo de resposta
(veremos maiores detalhes na aula de administração de banco de dados).

8.2. Recursos e Componentes Internos

Trata-se da parte inferior da figura, onde vários componentes são utilizados por meio das
diversas chamadas feitas pelos usuários, fazendo uso do processador de banco de dados em
tempo de execução, trabalhando junto com o catálogo do sistema, podendo atualizá-lo com as
estatísticas de uso do banco dados. O processador do banco de dados, quando em execução,
também gerencia a transferência de dados, fazendo uso do gerenciador de buffer, componente
importante para garantir performance, evitando leituras constantes no disco, mas nem todos
os SGBDs tem este recurso nativo, alguns recorrem ao controle de buffer através do sistema
operacional.
Os sistemas de controle de concorrência, backup e recuperação são apresentados como
um módulo da figura. Eles são integrados ao processador de banco de dados em tempo de
execução para fins de gerenciamento de transação. Estes controles são fundamentais para ga-
rantir o funcionamento adequado do SGBD, uma vez que incidentes podem acontecer e se faz
necessário existir recursos para recuperação em caso de falha e isso é feito pelo controle de
backup. O controle de transações também deve existir, garantindo concorrências controladas
em dados, evitando assim inconsistências.
Bom, é isso, agora vem uma bateria de questões de concursos, onde irei comentar cada
uma delas.
Até a próxima aula e bons estudos!
 RESUMO
Prezado(a) aluno(a), finalizamos a nossa aula, agora vamos revisar todo assunto, trazendo
os principais pontos para que você possa relembrar do que foi visto e partir para a resolução
de questões. Vamos lá!

Banco de Dados:
• Representa aspectos do mundo real;
• Todas as mudanças ocorridas devem ser refletidas no mundo real devem ser refletidas
no banco dados;
• É projeto, construído e populado (publicado) com dados para uma finalidade específica.
• Possui grupo definido de usuários e algumas aplicações previamente concebidas nas
quais estes usuários são interessados.

Dados, Informações, Conhecimento e Inteligência:

• Dados: Resultados de eventos do mundo real, sendo considerado como “dado bruto”,
onde fora de um contexto específico não representa informação;
• Informações: Definido dentro de um contexto específico, para que produzam informa-
ção fazem uso dos dados, que foram processados. A partir da informação é possível
produzir interpretação;
• Conhecimento: O conhecimento tem relação com a capacidade de alguém interpretar e
sintetizar um conjunto de informações. É a informação em ação, gerando conhecimen-
to. Não é estático, muda e evolui a todo tempo, com base na interação com o ambiente;
• Inteligência: É a base do processo decisório, podendo definir a direção estratégia de
uma organização. Pode gerar vantagem competitiva para uma organização.
 Sistemas Gerenciadores de Banco de Dados (SGBD)

Um Sistema Gerenciador de Banco de Dados – SGBD é uma coleção de programas que

permite aos usuários criar e manter um banco de dados. O SGBD é um sistema de software de
uso geral que facilita o processo de definição, construção, manipulação e compartilhamento
de banco de dados entre diversos usuários e aplicações.
Trata de todo o acesso ao banco de dados. Um usuário faz um pedido de acesso usando
uma linguagem (geralmente SQL). O SGBD intercepta o pedido e o analisa. O SGBD, por sua
vez, inspeciona o esquema externo (ou as versões objeto desse esquema) para esse usuário, o
mapeamento externo/conceitual correspondente, o esquema conceitual, o mapeamento con-
ceitual/interno e a definição do banco de dados armazenado.
As definições ou informações sobre o banco de dados são armazenadas no SGBD através
do catálogo ou dicionário de dados, também chamado de metadados. Nestes metadados fica-
rão registrados os tipos, estruturas e restrições dos dados armazenados.
Todas as tabelas estão fisicamente no banco de dados na forma de arquivos, cada tabela
ao ser criada é definida os tipos de dados de cada coluna. Quando uma linha da tabela é pre-
enchida, dizemos temos ali um registro.
Não esqueça:
• Tabela = Relação;
• Coluna = atributo;
• Uma tabela tem uma ou mais colunas;
• Registro corresponde a uma linha na tabela, com todas as colunas;
• Relacionamento é o vínculo entre uma ou mais tabelas. Para formar estes vínculos, al-
guns atributos precisam existir em comum nestas tabelas.

As 4 principais características que tornam vantajosa a utilização de um SGBD:

 Quando falamos em Transações e controles de concorrência, precisamos lembrar dos prin-
cípios do ACID: Atomicidade, Consistência, Isolamento e Durabilidade.
Atomicidade: É a propriedade que garante que a transação seja tratada de forma única, a
qual deve ser executada por completo ou em caso de falha, que seja falha por completo, não
deixando parte das operações sendo executadas com sucesso e outras fiquem pendentes,
causando inconsistências futuras nos dados. É regra do “tudo ou nada”.
Consistência: Deve garantir que a transação leve o banco de dados de um estado válido
para outro, mantendo a estabilidade do banco de dados.
Isolamento: É a propriedade que irá garantir que durante transações, o acesso simultâneo
a um mesmo dado seja tratado como se fosse sequencial, sem que haja falha. As transações
serão escalonadas, evitando assim deadlock e travamento.
Durabilidade: É propriedade que o SGBD deve ter de que uma transação já executada (efe-
tivada), permaneça neste estado mesmo havendo algum problema de falha no sistema algum
travamento em sistema operacional ou até mesmo queda de energia.

Evolução e Tipos de SGBDs

Modelo Hierárquico (Década de 60): Os dados eram organizados formando uma hierar-
quia, semelhante a uma árvore de dados, sendo que cada nó desta hierarquia possui ocorrên-
cias de registros, sendo cada registro uma coleção de campos (ou atributos), onde cada um
contém um dado.
Modelo em Rede (Década de 60): Uma extensão do modelo hierárquico, sendo as relações
de dados representadas por grafos bidirecionais.
Modelo Relacional (Década de 70): Devido a inflexibilidade dos modelos anteriores, no to-
cante a necessidade de reorganização dos dados a cada manipulação, surge então o modelo
relacional atendendo a algumas necessidades, tais como: independência entre dados e pro-
grama, dados de um lado e estrutura física do outro. Os dados são armazenados em relações
(tabelas), onde cada tabela possui uma ou mais colunas (atributos). Utiliza uma linguagem
denominada SQL para realizar diversas operações sobre os dados, bem como criação da es-
trutura do banco de dados(esquema).
Modelo Orientado a Objetos (Década de 80): Mesmo o modelo relacional se mostrando
satisfatório, algumas áreas de atuação do mercado sentiram a necessidade da existência de
um modelo onde se pudesse ter flexibilidade na definição dos tipos dados, podendo também
definir métodos de comportamento sobre os dados. O objeto sendo estrutura (propriedade) +
operações(métodos).
Modelo NoSQL (Anos 2000): Com o crescimento exponencial dos dados no mundo, o uso
apenas de SGBDs estruturados, onde a definição da estrutura dos dados era conhecida pre-
viamente, perde o sentido, uma vez que a origem dos dados nem sempre é conhecida. Neste
contexto surgem os SGBDs NoSQL (Not Only SQL), proporcionando armazenamento de dados
estruturados e semiestruturados (como arquivos JSON, XML, por exemplo). Reveja os tipos
NoSQL abaixo:
 − Modelo orientado a chave-valor;
− Modelo orientado a documentos;
− Modelo orientado a colunas;
− Modelo orientado a grafos.

Esquemas e Instâncias do Banco de Dados

Esquema (Schema)

É a descrição da estrutura do banco dados. O catálogo de dados guarda informações so-

bre as definições das elações (tabelas) e dos relacionamentos (vínculo entre as tabelas), onde
várias propriedades são definidas como, por exemplo: os tipos e tamanhos dos campos (atri-
butos), quais desses atributos serão utilizados nos relacionamentos entre tabelas, ou seja, a
definição das chaves primárias e chaves estrangeiras, bem como também regras de restrições,
ou seja, a definição da obrigatoriedade ou não do preenchimento de determinado atributo.

Instância

É o banco de dado populado, posto em uso, utilizando a estrutura ou esquema de dados já

definido. Resumindo, a instância utiliza o esquema.
 Nível Físico, Nível Lógico e Nível de Visão (Segundo Silberschatz-Korth-Su-
darshan)

Nível Físico: O nível de abstração mais baixo, descreve em detalhes estruturas de dados
complexas de baixo nível.
Nível Lógico: Descreve o banco de dados inteiro em termos de um pequeno número de
estruturas relativamente simples.
Nível de view: O nível de abstração mais alto descreve apenas parte do banco de dados.
O nível de view existe para simplificar sua interação com o sistema. O sistema pode fornecer
muitas visões para o mesmo banco de dados.
 Arquitetura em Três Esquemas (ANSI/SPARC) e a Independência de Dados
Arquitetura em Três Esquemas

Nível Externo: Está mais próximo do usuário e longe dos aspectos físicos do banco de da-
dos, é o que chamamos também de modelo de dados de alto nível.
Nível Conceitual: Oculta os detalhes das estruturas de armazenamento físico e foca na
descrição representativa das entidades, tipos de dados, relacionamentos, restrições e opera-
ções dos usuários. A construção deste esquema conceitual toma por base o modelo de dados
de alto nível, presente no nível externo.
Nível Interno: Neste nível todos os detalhes sobre o armazenamento e caminhos de aces-
so, são detalhados.
 Independência de Dados

Cuidado, existe uma ressalva:

Em geral, a independência física de dados existe na maioria dos bancos de dados e am-
bientes de arquivo, nos quais detalhes físicos, como a localização exata dos dados no disco,
e detalhes de hardware sobre codificação do armazenamento, posicionamento, compactação,
divisão, mesclagem de registros, e assim por diante, são ocultados do usuário. As demais apli-
cações ignoram esses detalhes. Por sua vez, a independência lógica de dados é mais difícil de
ser alcançada porque permite alterações estruturais e de restrição sem afetar os programas
de aplicação – um requisito muito mais estrito.
Projeto de um Sistema de Banco de Dados

Atenção especial para os seguintes itens:

• Levantamento e Análise de Requisitos e Projeto conceitual independem do SGBD que
será utilizado;
• O Projeto Lógico tem por objetivo transformar o modelo conceitual em um modelo ló-
gico, definindo como o banco de dados será implementado em um SGBD específico
(MySQL, PostgreSQL, Oracle, SQLServer, dentre outros);
• O Projeto Físico nesta etapa o modelo do banco de dados é enriquecido com detalhes
que influenciam no seu desempenho, como, por exemplo, definições de índices e con-
sulta.
 O Ambiente do Sistema de Banco de Dados

Os DBAs são os Administradores de Banco de Dados (Data Base Administrator), ele execu-
ta atividades de criação da estrutura de um banco de dados através da linguagem DDL (Data
Definition Language), uma das categorias da linguagem SQL. Os DBAs utilizam interfaces inte-
rativas, onde é possível informar os comandos DDL e ele é compilado e executado, por fim irá
refletir no catálogo do sistema onde ficam armazenados toda estruturas dos esquemas(me-
tadados) dos bancos de dados. Ele pode criar um banco de dados, novas tabelas e atributos,
também podem alterar a estrutura das que já existem, dentre outras atividades. Também po-
dem executar comandos com mais privilégios do que um usuário comum, como por exemplo,
podem inserir um lote de registros em uma determinada tabela via comandos SQL, neste caso
o comando será processado e executado com destino na instancia do banco de dados em uso
no momento.
Os programadores de aplicação podem executar comandos SQL, porem normalmente nas
categorias DQL (Data Query Manipulation), utilizado para consulta aos dados e DML (Data
Manipulation Language) que são comandos para manipulação de dados e não criação, alte-
ração ou exclusão de estruturas (geralmente em uma organização ou fábrica de software, o
gerenciamento das estruturas das tabelas e do próprio banco de dados, fica a cargo de um
DBA – Administrador de Banco de Dados e/ou AD – Administrador de Dados, porém em outros
cenários, o programador pode atuar em todas as frentes). Os programadores também podem
executar comandos que possam atuar em dados que estejam também sendo utilizados por
outros usuários, o que irá requerer o controle de concorrência através da utilização de transa-
ções. Essas transações são executadas pelos usuários paramétricos (abstração usada pelo
autor da figura), sendo considera cada transação como sendo uma execução separada.
Os usuários casuais, são os usuários do dia a dia, que utilizam aplicações já desenvolvidas
por alguma empresa ou algum programador/desenvolvedor.
As consultas aos dados via comando, são analisadas pelo compilador da consulta, pas-
sando para uma linguagem de uso interno do SGBD.
Outros componentes são utilizados por meio das diversas chamadas feitas pelos usuários,
fazendo uso do processador de banco de dados em tempo de execução, trabalhando junto
com o catálogo do sistema, podendo atualizá-lo com as estatísticas de uso do banco dados.
O processador do banco de dados, quando em execução, também gerencia a transferência
de dados, fazendo uso do gerenciador de buffer, componente importante para garantir per-
formance, evitando leituras constantes no disco, mas nem todos os SGBDs tem este recurso
nativo, alguns recorrem ao controle de buffer através do sistema operacional.
Os sistemas de controle de concorrência, backup e recuperação são apresentados como
um módulo da figura. Eles são integrados ao processador de banco de dados em tempo de
execução para fins de gerenciamento de transação. Estes controles são fundamentais para
garantir o funcionamento adequado do SGBD, uma vez que incidentes podem acontecer e se
faz necessário existir recursos para recuperação em casos de falha e isso é feito pelo controle
de backup.
 MAPA MENTAL
Nível Externo
Nível Conceitual
Arquitetura 3 Níveis
Nível Interno
(Elmasri e Navathe) Representa aspectos do
mundo real Mudanças ocorridas são
Lógica refletidas na banco de
Independência de Dados Finalidade específica dados
Física
Grupo específico de usu-
ários
Nível de View
Nível Lógico Modelo 3 Níveis
Nível Físico Características

Modelo Hierárquico
DDL Cria e altera estrutura de dados
Modelo em Rede
Banco de Cria e mantém bancos
DQL Consulta e obtém dados
Modelo Relacional de dados SQL
Evolução Dados DML Inclui, altera e exclui dados
Modelo Orientado a Objetos
Modelo NoSQL
Controle de transações
Acessado por diversos
Natureza de autodescrição de um usuários Atomicidade

sistema de banco de dados ACID Consistência

Isolamento entre programas e dados, Características SGBD Isolamento

e abstração de dados
do SGBD (4) Durabilidade
Suporte para múltiplas visões de Tipos
dados
Estruturas
Catálogo de Dados Armazena definições sobre o BD
Compartilhamento de dados e proces-
Restrições
samento de transação multiusuário

Tabela = Relação

Coluna = Atributo
Dica
Uma tabela tem uma ou
mais colunas

Registro = linha da tabela

com todas colunas

Relacionamento = vínculo
entre tabelas
Introdução à linguagem

SQL
 1
Banco de Dados
Banco de Dados é um conjunto de informações organizadas
que podem estar em um sistema manual ou em um sistema
computadorizado.

Em um sistema manual, as informações são armazenadas

em arquivos, dentro de gavetas, e a recuperação e consulta
destas informações é bastante trabalhosa, pois exige uma
pesquisa manual.

Em um sistema de computador, as informações são

armazenadas em meios magnéticos, e a recuperação das
informações é feita através de softwares específicos.

Vantagens no uso de computador:

Além disso, um SGBD deve proporcionar a segurança das
♦ Recuperação e atualização rápida das informações; informações armazenadas no banco de dados, mesmo em
♦ Informação ocupa menos espaço (meios magnéticos); caso de queda no sistema ou de tentativas de acessos não

♦ Vários usuários podem compartilhar as informações; autorizados.

Os dados em um SGBD podem ser compartilhados entre

♦ Inexistência dados redundantes;
diversos usuários. Para isso, um SGBD deve possuir formas
♦ Inexistência de valores inconsistentes;
de compartilhamento do banco de dados.
♦ Definição de regras de segurança no acesso aos dados
Devido à importância da informação na maioria das
Sistema Gerenciador de Banco de organizações, o banco de dados é um recurso valioso. Isso
Dados tem levado ao desenvolvimento de uma larga gama de
Um sistema de gerenciamento de banco de dados (SGBD) conceitos e técnicas para o gerenciamento eficiente dos
consiste de uma coleção de dados inter-relacionados e um dados.
conjunto de programas (software) para acessar esses dados.
Componentes de um SGBD
A coleção de dados é comumente chamada de banco de
Basicamente, um SGBD nada mais é do que um sistema de
dados. O principal objetivo de um SGBD é proporcionar
armazenamento de dados baseado em computador; isto é,
um ambiente conveniente e eficiente para recuperar e
um sistema cujo objetivo global é registrar e manter
armazenar informações no banco de dados.
informações.
Os SGBDs são concebidos para gerenciar grandes
Um SGBD é composto de quatro componentes básicos:
quantidades de informação. O gerenciamento dos dados
hardware, dados, software e usuários.
envolve tanto a definição de estruturas para armazenamento
das informações como a implementação de mecanismos Hardware
para a manipulação dessas informações. Consiste dos meios de armazenamentos de dados – discos,
fitas, etc. – nos quais reside o banco de dados, juntamente
com os dispositivos associados a esses meios.

Dados
Os dados armazenados no sistema são repartidos em um ou
mais banco de dados. Um banco de dados é um depósito de
 Banco de dados
dados armazenados. Geralmente ele é integrado e exatamente quais informações devem ser mantidas. Deve
compartilhado. identificar as entidades que interessam à empresa e as

Por “integrado” quer-se dizer que o banco de dados pode informações a serem registradas sobre essas entidades.

ser imaginado como sendo a unificação de diversos É função do DBA servir como elemento de ligação com os
arquivos, eliminando total ou parcialmente qualquer usuários, para garantir a disponibilidade dos dados que eles
redundância entre estes arquivos. necessitam. Ele é responsável também pela organização e

Por “compartilhado” quer-se dizer que partes individuais desempenho do sistema tendo em vista “o melhor para a

dos dados podem ser acessadas por diversos usuários empresa”.

diferentes. O compartilhamento é na realidade uma

Por que Banco de Dados?
conseqüência do banco de dados ser integrado. O termo
Um Banco de Dados proporciona à empresa um controle
“compartilhado” é freqüentemente expandido para cobrir
centralizado de seus dados operacionais, um de seus ativos
também o compartilhamento concorrente; isto é, a
mais valiosos.
capacidade de que diversos usuários diferentes estejam
Dentre as diversas vantagens de um SGBD, pode-se
tendo acesso ao banco de dados ao mesmo tempo.
destacar as seguintes:
Software
♦ Eliminação de redundâncias de dados armazenados;
Entre o banco de dados físico (isto é, os dados
♦ Evitar inconsistência de dados;
armazenados) e os usuários do sistema encontra-se uma
camada de software que é propriamente o sistema de ♦ Os dados podem ser compartilhados;
gerenciamento de banco de dados. Todas as solicitações dos ♦ Fácil utilização de padrões;
usuários para acessar o banco de dados são manipulados ♦ Restrições de segurança;
pelo SGBD.
♦ Manutenção da integridade dos dados.
Uma função geral provida pelo SGBD é isolar os usuário
do banco de dados dos níveis de detalhes de hardware. Em Independência de Dados
outras palavras, o SGBD fornece uma visão do banco de Dizemos que uma aplicação é dependente de dados quando
dados acima do nível de hardware. for impossível mudar a estrutura de armazenamento ou a
estratégia de acesso sem afetar a aplicação.
Usuários
A independência de dados é um objetivo maior dos
Pode-se identificar três classes de usuários. Primeiramente
sistemas de banco de dados. Podemos definir
temos o programador de aplicações, responsável por
independência de dados como a imunidade das aplicações a
escrever programas de aplicação que utilizam o banco de
mudanças na estrutura de armazenamento ou na estratégia
dados. Estes programadores operam com os dados de todas
de acesso.
as formas usuais: recuperando informações, criando novas
informações, retirando ou alterando informações existentes. Independência física
A segunda classe de usuários é o usuário final, que tem É a capacidade de modificar o esquema físico sem afetar os
acesso ao banco de dados a partir de um terminal. Um componentes do Banco de Dados. Por exemplo, criar um
usuário final pode utilizar uma linguagem de consulta novo índice em uma tabela.
fornecida como parte integrante do sistema (SQL, por
Independência lógica
exemplo), ou pode executar uma aplicação escrita pelo
É a capacidade de modificar o esquema conceitual sem
programador de aplicações.
necessidade de reescrever os programas aplicativos. Por
A terceira classe de usuário é o administrador de banco de
exemplo, criar um novo atributo em uma tabela.
dados (DBA). É parte do trabalho do DBA decidir

Pagina 2
 Banco de dados

Níveis de Abstração armazenadas. Pelo contrário, os usuários necessitam apenas

Sistema gerenciador de banco de dados é uma coleção de de uma parte do banco de dados para realizarem seu

arquivos inter-relacionados e um conjunto de programas trabalho. Para simplificar a interação desses usuários com o

que permitem a diversos usuários acessar e modificar esses sistema existe o nível externo, também chamado nível de

arquivos. Um propósito central de um sistema de banco de visão. Pode haver diferentes visões para um mesmo banco

dados é proporcionar aos usuários uma visão abstrata dos de dados.

dados. Isto é, o sistema esconde certos detalhes de como os

dados são armazenados ou mantidos. Porém, para que o
sistema seja utilizável, os dados precisam ser recuperados
eficientemente.

A preocupação com a eficiência leva a concepção de

estruturas de dados complexas para a representação dos
dados no banco de dados. Porém, uma vez que sistemas de
banco de dados são freqüentemente usados por pessoal sem
Linguagem de Definição de Dados
treinamento na área de informática, esta complexidade
Um esquema de banco de dados é especificado por um
precisa ser escondida dos usuários do sistema. Isto é
conjunto de definições que são expressas em uma
conseguido definindo-se diversos níveis de abstração pelos
linguagem especial chamada linguagem de definição de
quais o banco de dados pode ser visto.
dados (DDL). O resultado da execução de instruções DDL
Nível físico ou interno é um conjunto de tabelas que são armazenadas num arquivo
Este é o nível mais baixo de abstração, no qual se descreve especial chamado dicionário de dados (ou diretório de
como os dados são armazenados. Neste nível, estruturas dados).
complexas, de baixo nível, são descritas em detalhe. Um diretório de dados é um arquivo que contém
metadados; isto é, “dados acerca dos dados”. Este arquivo é
Nível conceitual
consultado antes que os dados reais sejam lidos ou
Este nível é onde se descreve quais dados são armazenados
modificados no sistema de banco de dados.
e quais os relacionamentos existentes entre eles. Este nível
descreve o banco de dados como um pequeno número de Linguagem de Manipulação de
estruturas relativamente simples. Muito embora a Dados
implementação de estruturas simples possa envolver Entenda-se por manipulação de dados:
estruturas complexas no nível físico, o usuário do nível
♦ A recuperação de informação armazenada no banco de
conceitual não necessita estar ciente disso. O nível
dados;
conceitual é usado pelos administradores do banco de
♦ A inserção de novas informações no banco de dados;
dados, que devem decidir qual informação deve ser mantida
no banco de dados. ♦ A remoção de informações do banco de dados

No nível físico, precisamos definir algoritmos que

Nível externo
permitam o acesso aos dados de forma eficiente. Em níveis
Este é o nível mais alto de abstração, no qual se expõe
mais altos de abstração a ênfase está na facilidade de uso. O
apenas parte do banco de dados. Apesar do nível conceitual
objetivo principal é proporcionar uma eficiente interação
utilizar estruturas mais simples, há ainda um tipo de
humana com o sistema.
complexidade resultante do grande tamanho do banco de
dados. Muitos dos usuários do sistema de banco de dados
não estarão preocupados com todas as informações

Pagina 3
 Banco de dados
Uma linguagem de manipulação de dados (DML) é uma Cliente_conta Conta
linguagem que permite aos usuários acessar ou manipular Cód_cli Cód_cc Cod_CC Saldo

dados organizados por um modelo de dados apropriado. 01 900 900 55,00

02 556 556 100000,00
Modelo de Dados 02 647 647 105366,00
03 647 801 10533,00
Modelo de dados é uma coleção de ferramentas conceituais
03 801
para descrição dos dados, relacionamentos entre os dados,
semântica e restrição dos dados. Diversos modelos de dados Modelo de rede
foram propostos, e estão divididos em três grupos: Os dados no modelo de rede são representados por coleções
♦ Modelos baseados em objetos; de registros e os relacionamentos entre os dados são
representados por ligações que podem ser vistas como
♦ Modelos baseados em registros;
apontadores. Os registros no banco de dados são
♦ Modelos físicos.
organizados como coleções de grafos.
Os modelos que iremos nos concentrar são os modelos
baseados em registros.

Modelos Baseados em Registros

Modelos lógicos baseados em registros são usados na
descrição de dados nos níveis conceitual e externo (visão).
Modelo Hierárquico
Esses modelos são usados para especificar tanto a estrutura
O modelo hierárquico é similar ao modelo de rede no
lógica global do banco de dados como uma descrição em
sentido em que dados e relacionamento são representados
alto nível de implementação.
por registros e ligações, respectivamente. O modelo
hierárquico difere do modelo em rede porque os registros
são organizados como coleções de árvores em vez de
grafos.

Modelo Relacional
No modelo relacional os dados e os relacionamentos entre
os dados são representados por uma coleção de tabelas,
cada qual com um número de colunas. Para ilustrar isto,
considere um banco de dados composto de clientes e
contas.

Cliente
Cod_Cli Nome Rua Cidade Banco de Dados Cliente/Servidor
01 José Pio XI São Paulo Na arquitetura Cliente/Servidor o banco de dados fica
02 Maria São Francisco Recife
residente em um computador chamado servidor e suas
03 Gabriela do Sol Maceió
informações são compartilhadas por diversos usuários que
executam aplicações em seus computadores locais
(clientes). Essa arquitetura propicia uma maior integridade
dos dados, pois todos os usuários estarão trabalhando com a
mesma informação. A arquitetura Cliente/Servidor reduz

Pagina 4
 Banco de dados
consideravelmente o tráfego de rede, pois retorna ao mas ainda assim disponível (via rede de comunicação) aos
usuário apenas os dados solicitados. Por exemplo, uma base usuários de outros locais. As vantagens dessa distribuição
de dados com cem mil registros, se for feita uma pesquisa são claras: combinam a eficiência do processamento local
que encontre apenas três registros, somente esses três (sem sobrecarga de comunicações) na maioria das
registros serão enviados pela rede para a máquina cliente. operações, com todas as vantagens inerentes aos bancos de
dados. Mas, naturalmente, também há desvantagens: podem
Bancos de Dados Distribuídos
ocorrer sobrecargas de comunicação, além de dificuldades
Um banco de dados distribuído é aquele que não é
técnicas significativas para se implementar esse sistema.
inteiramente armazenado em uma única localização física,
O objetivo principal em um sistema distribuído é o de que
estando disperso através de uma rede de computadores
ele pareça ser, ao usuário, um sistema centralizado. Isto é,
geograficamente afastados e conectados por elos de
normalmente o usuário não precisará saber onde se
comunicação. Como um exemplo bastante simplificado,
encontra fisicamente armazenada determinada porção dos
consideremos o sistema de um banco no qual o banco de
dados. Portanto, o fato de ser o banco de dados distribuído
dados das contas dos clientes esteja distribuído pelas
só deve ser relevante ao nível interno, e não aos níveis
agências desse banco, de tal forma que cada registro
externo e conceitual.
individual de conta de cliente se encontre armazenado na
agência local do cliente. Em outras palavras, o dado esteja
armazenado no local no qual é mais freqüentemente usado,

Pagina 5
 2
O Modelo Relacional
Os primeiros sistemas de banco de dados se baseavam no Cliente ⇒ Relação ou tabela
modelo hierárquico ou no modelo em rede. Em junho de Código Nome Endereco ⇒ Atributo, coluna ou campo
1970 o Dr. E.F. Codd escreveu no artigo “Um Modelo 123 João Rua Pio XI
567 Maria Rua S. Francisco
Relacional de Dados para banco de dados compartilhados”
678 Joana Av. Liberdade ⇒ Tupla, linha ou registros
o que foi considerado o primeiro projeto de um modelo 876 Gabriela Av. Jatiúca
relacional para sistema de banco de dados. 976 Ana Júlia Av. São Paulo

O modelo de dados relacional representa o banco de dados O conjunto formado pelos atributos de uma relação é
como uma coleção de tabelas. Muito embora “tabelas” também chamado de Domínio.
envolvam noções simples e intuitivas, há uma
correspondência direta entre o conceito de tabela e o Álgebra Relacional
conceito matemático de relação. A álgebra relacional é um conjunto de operações realizadas
sobre relações. Cada operação usa uma ou mais relações
Nos anos seguintes à introdução do modelo relacional, uma
como seus operandos, e produz outra relação como
teoria substancial foi desenvolvida para os bancos de dados
resultado.
relacionais. Esta teoria auxilia na concepção de banco de
dados relacionais e no processamento eficiente das As operações tradicionalmente usadas na teoria dos
requisições de informação feitas pelos usuários do banco de conjuntos (união, interseção, diferença e produto
dados. cartesiano) podem também ser definidas em termos de
relação. Em todas, com exceção do produto cartesiano, as
Relação duas relações do operando têm que ser união-compatíveis,
Como o próprio nome diz, uma relação é a “matéria prima” isto é, elas devem possuir a mesma estrutura.
para a construção de toda a teoria do modelo relacional e,
A união de duas relações A e B é o conjunto de todas as
por conseqüência, é o alicerce teórico de todo sistema de
tuplas que pertencem a A ou B.
banco de dados baseado no modelo relacional.
A interseção de duas relações A e B é o conjunto de todas
Nos sistema de banco de dados relacionais as relações são
as tuplas que pertencem a A e B.
representadas através de tabelas. Uma tabela é geralmente
A diferença entre duas relações A e B (nessa ordem) é o
uma entidade identificada no processo de análise do sistema
conjunto de todas as tuplas que pertencem a A mas não a B.
que se está implementando.
O produto cartesiano de duas relações A e B é o conjunto
Uma tabela é constituída de linhas e colunas. Toda tabela
de todas as tuplas t tais que t é a concatenação de uma tupla
deve possuir um nome e um conjunto de atributos (ou
a de A com uma tupla b pertencente a B.
campos). As colunas que representam os atributos da tabela
devem também possuir um nome, juntamente com o tipo de
dado que será armazenado na coluna.

Cada conjunto de atributos forma uma linha (ou registro)

que pode ser chamado também de tupla.
 O Modelo Relacional
tuplas (linhas) dentro da relação dada que satisfaz a uma
condição especificada.

O operador projeção produz um subconjunto “vertical” de

uma dada relação. Isto é, o subconjunto obtido pela seleção
de atributos (colunas) especificados.

O operador algébrico de seleção produz um subconjunto

“horizontal” de uma dada relação. Isto é, o subconjunto de

Pagina 7
 3
A Linguagem SQL
Embora se fale que a linguagem SQL é uma linguagem de
Data Control Language (DCL)
consulta, essa linguagem possui outras capacidades além de
É o conjunto de comandos que fazem o cadastramento de
realizar consultas em um banco de dados. A linguagem
usuários e determina seu nível de privilégio para os objetos
SQL possui recursos para definição da estrutura de dados,
do banco de dados. Os principais comandos são: GRANT,
para modificar dados no banco de dados e recursos para
REVOKE.
especificar restrições de segurança e integridade.

A versão original da linguagem SQL foi desenvolvida no Transactions control.

laboratório de pesquisa da IBM. Esta linguagem, A SQL inclui comandos para especificação do início e fim

originalmente chamada SEQUEL, foi implementada como das transações. Diversas implementações permitem o

parte do projeto System R no início dos anos 70. A trancamento explícito de dados para o controle de

linguagem SEQUEL evoluiu e seu nome foi mudado para concorrência. (COMMIT, ROLLBACK, SAVEPOINT)

SQL (Strutured Query Language). A SQL estabeleceu-se

Tipos de Dados
como a linguagem padrão de consultas a banco de dados
Os tipos de dados existentes na linguagem SQL variam de
relacional. Vários Sistemas Gerenciadores de Banco de
acordo com a versão e fabricante. A primeira versão,
Dados suportam a linguagem SQL.. Embora existam
surgida por volta de 1970, não possuía tipos de dados para
diversas versões, com algumas diferenças entre elas, a
armazenamento de informações multimídia como som,
estrutura da SQL se mantém inalterada desde a sua criação.
imagem, vídeo; tão comuns nos dias de hoje. A maioria dos
Um comitê foi criado para padronizar a linguagem na Sistemas Gerenciadoras de Banco de Dados incorporou
tentativa de torna-la independente de plataforma. O padrão esses novos tipos de dados às suas versões da linguagem
SQL é definido pelo ANSI (Amarican National Standards SQL. Os tipos apresentados abaixo fazem parte do conjunto
Institute). de tipos do padrão ANSI 92 da linguagem SQL.

As partes da linguagem SQL CHAR(n)

Armazena caracteres alfanuméricos de
tamanho fixo n.
A linguagem SQL pode ser dividida em diversas partes. Cadeia de caracteres de comprimento
VARCHAR(n)
Algumas dessas partes serão apresentadas a seguir. variável e tamanho máximo de n caracteres.
INTEGER Dado numérico inteiro de tamanho fixo.
Data Definition Language (DDL) DECIMAL(n, m) Dado numérico de tamanho variável, sendo
n o número total de dígitos e m o número de
A SQL DDL fornece comandos para definição e NUMERIC(n,m) casas decimais.
modificação de esquemas de relação, remoção de relações e BIT(n) Seqüência n de bits.
criação de índices. Os principais comandos que fazem parte TIME Hora de tamanho fixo.
DATE Data de tamanho fixo.
da DDL são: CREATE, ALTER, DROP.

Data Manipulation Language (DML)

A SQL DML inclui uma linguagem de consulta baseada na
álgebra relacional e no cálculo relacional. Compreende
também comandos para inserir, remover e modificar
informações em um banco de dados. Os comandos básicos
da DML são: SELECT, INSERT, UPDATE, DELETE.
 4
A Linguagem de
Definição de Dados
Departamento prevenindo a entrada de informações inválidas pelos
Código Decimal(5) usuários desse sistema. Para isso, o Sistema de Banco de
Nome Char(20) Dados deve possibilitar a definição de regras de integridade
Funcionario a fim de evitar a inconsistência dos dados que nele serão
Matricula Decimal(5) armazenados.
Nome Char(30)
RG Decimal(9) Chave Primária
Sexo Char(1) A função da chave primária é identificar univocamente
Depto Decimal(5) cada registro da tabela. Toda tabela deve possuir uma chave
Endereco Varchar(50)
primária, que deve ser composta por um ou mais campos.
Cidade Char(20)
Salário Decimal(10,2) create table departamento
(Codigo decimal(5) NOT NULL PRIMARY KEY,
A Linguagem de Definição de Dados (DDL) é um conjunto Nome char(20) )

específico de instruções SQL que fornece meios para a

create table funcionario
criação, alteração e exclusão de tabelas e índices. (matricula decimal(5) NOT NULL PRIMARY KEY,
nome char(30),
Criando tabelas rg decimal(9),
sexo char(1),
Uma tabela é definida usando o comando CREATE depto decimal(5),
TABLE. endereço varchar(40),
cidade varchar(20),
create table T (A1 D1, A2 D2,...) salário decimal(10,2) )
onde T é o nome da tabela, Ai é o nome do campo da tabela T e
Di é o tipo do campo Ai. Observação:
No Interbase é obrigatória a utilização da cláusula NOT
create table departamento
(Codigo decimal(5),
NULL para o(s) campo(s) da chave primária.
Nome char(20) )
Opcionalmente pode-se definir a chave primária após a
create table funcionario especificação de todos os atributos da tabela.
(matricula decimal(5),
create table funcionario
nome char(30),
(matricula decimal(5) NOT NULL,
rg decimal(9),
nome char(30),
sexo char(1),
rg decimal(9),
depto decimal(5),
sexo char(1),
endereco varchar(40),
depto decimal(5),
cidade varchar(20),
endereço varchar(40),
salário decimal(10,2) )
cidade varchar(20),
salario decimal(10,2),
Uma tabela é criada inicialmente vazia, sem registros. O
PRIMARY KEY (matricula) )
comando INSERT, que será visto posteriormente, é usado
para carregar os dados para a relação. Quando uma tabela possui uma chave primaria composta
por mais de um campo esta forma é obrigatória.
Restrições de Integridade
As restrições de integridade servem para garantir as regras
inerentes ao sistema que está sendo implementado,
 A Linguagem de Definição de Dados DDL
Evitando valores nulos Definindo valores default
É muito comum definirmos campos que não podem conter Pode-se definir um valor padrão para um campo
valores nulos. Isto é, o seu preenchimento do campo é acrescentando à sua definição a cláusula DEFAULT. Esta
obrigatório para que se mantenha a integridade dos dados cláusula permite substituir automaticamente os valores
no sistema. nulos por um valor inicial desejado.

Para evitar que em algum momento um campo de uma create table funcionario
(matricula decimal(5) NOT NULL PRIMARY KEY,
tabela possa conter valor nulo (null) deve-se utilizar a nome char(30) NOT NULL,
cláusula NOT NULL após a definição do campo. rg decimal(9) NOT NULL UNIQUE,
sexo char(1),
create table funcionario
depto decimal(5),
(matricula decimal(5) NOT NULL PRIMARY KEY,
endereço varchar(40),
nome char(30) NOT NULL,
cidade varchar(20) DEFAULT ‘São Paulo’,
rg decimal(9),
salario decimal(10,2) )
sexo char(1),
depto decimal(5),
endereço varchar(40), Evitando valores inválidos
cidade varchar(20), Existem situações onde um campo pode receber apenas
salario decimal(10,2) )
alguns determinados valores. Para que o valor de um campo
No exemplo acima, o preenchimento do campo nome será fique restrito a um determinado conjunto de valores, utiliza-
obrigatório. Caso o usuário se esqueça de preenche-lo, o se a cláusula CHECK.
SGBD apresentará uma mensagem de erro. create table funcionario
(matricula decimal(5) NOT NULL PRIMARY KEY,
Evitando valores duplicados nome char(30) NOT NULL,
rg decimal(9) UNIQUE,
Podem existir situações onde o valor armazenado em um
sexo char(1) CHECK( sexo in (‘M’, ‘F’) ),
campo de um registro deve ser único em relação a todos os depto decimal(5),
registros da tabela. Isto é, não pode haver dois registros endereco varchar(40),
cidade varchar(20) DEFAULT ‘São Paulo’,
com o mesmo valor para um determinado campo. salario decimal(10,2) CHECK(salario>350) )

Para implementar esta restrição de integridade deve-se

utilizar a cláusula UNIQUE após a especificação de uma Integridade referencial
coluna. Freqüentemente desejamos que o valor armazenado em um

create table funcionario

determinado campo de uma tabela esteja presente na chave
(matricula decimal(5) NOT NULL PRIMARY KEY, primária de outra tabela. Este atributo é chamado chave
nome char(30) NOT NULL,
estrangeira (FOREIGN KEY). Por exemplo, o campo
rg decimal(9) NOT NULL UNIQUE,
sexo char(1), depto da tabela funcionario deve conter o código de um
depto decimal(5),
departamento anteriormente cadastrado na tabela
endereço varchar(40),
cidade varchar(20), departamento. Para que essa restrição seja sempre
salario decimal(10,2) ) observada, utiliza-se a cláusula REFERENCES na

No exemplo acima, caso o usuário atribua ao campo RG um definição do campo depto da tabela funcionario.

valor já existente em outro registro desta mesma tabela, o O campo depto da tabela funcionario é portanto uma chave
SGBD apresentará uma mensagem de erro. estrangeira e só será permitido armazenar valores que
estejam previamente cadastrado no campo codigo da tabela
Observação: departamento.
No Interbase é obrigatória a utilização da cláusula NOT
NULL juntamente com a cláusula UNIQUE.

Pagina 10
 A Linguagem de Definição de Dados DDL
create table funcioário alter table T
(matricula decimal(5) NOT NULL PRIMARY KEY, drop A1,
nome char(30) NOT NULL, drop A2,
. . .
rg decimal(9) NOT NULL UNIQUE,
sexo char(1) CHECK( sexo in (‘M’, ‘F’), onde T é o nome de uma tabela e Ai é uma lista dos atributos a
depto decimal(5) REFERENCES departamento(codigo), serem removidos.
endereco varchar(40), Para alterar o nome de um atributo de uma tabela utiliza-se
cidade varchar(20) DEFAULT ‘São Paulo’,
salario decimal(10,2) CHECK(salario>350) )
a cláusula alter...to.
alter table T
Assim como na definição da chave primária, pode-se alter A1 to nA1,
alter A2 to nA2,
definir a chave estrangeira após a especificação de todos os . . .
campos da tabela. onde T é o nome de uma tabela, A é o nome do atributo a ter o
seu nome alterado para nA.
create table cliente
(matricula decimal(5) NOT NULL,
Exemplo:
nome char(30) NOT NULL,
rg decimal(9) NOT NULL UNIQUE, Alter table departamento
sexo char(1) CHECK(sexo in (‘M’, ‘F’)), Alter Codigo to dep_Codigo,
depto decimal(5), Alter Nome to dep_Nome
endereco varchar(40),
cidade varchar(20) DEFAULT ‘Sao Paulo’, Para alterar o tipo de um atributo utiliza-se a cláusula
primary key (matricula), alter...type.
FOREIGN KEY (depto) REFERENCES
departamento(codigo) ) alter table T
alter A1 type t1,
Removendo uma tabela alter A2 type t2,
. . .
Para remover uma relação de um banco de dados SQL, usa- onde T é o nome de uma tabela, A é o nome do atributo a ter o
se o comando DROP TABLE. O comando DROP TABLE seu tipo alterado para D.

remove todas as informações sobre a relação. Exemplo:

drop table T Alter table departamento
Alter nome type char(30)
onde T é o nome de uma tabela do banco de dados

Alterando uma Tabela Índices

Os índices são componentes do banco de dados destinados
O comando ALTER TABLE é usado para adicionar, excluir
a agilizar o acesso aos dados. Um índice pode ser associado
ou alterar atributos em uma tabela.
a uma coluna ou a uma combinação de várias colunas.
Incluir campos
Uma vez criado um índice, todas as alterações feitas à
Para inserir um novo atributo em uma tabela é usada a
tabela são automaticamente refletidas no índice. Pode-se
cláusula add. O novo campo terá valor null para todos os
criar vários índices para uma tabela.
registros da tabela.
As únicas instruções SQL que tratam de índices são
alter table T
add A1 D1, CREATE INDEX e DROP INDEX.
add A2 D2,
. . . Criando índices
onde T é o nome de uma tabela e Ai Di é uma lista contendo A instrução CREATE INDEX exige que se defina um nome
nome do atributo (Ai) a ser adicionado e o tipo desse atributo
(Di). para o índice a ser criado, seguido do nome da tabela e por
Excluir campos fim, uma lista contendo o nome dos atributos que compõem
Para excluir colunas de uma tabela utiliza-se a cláusula o índice.
drop.

Pagina 11
 A Linguagem de Definição de Dados DDL

create index i on T(A1, A2, ...) create UNIQUE index RG_Funcionario

on funcionario(RG)
Onde i é o nome do índice, T é o nome da tabela que se deseja
indexar e Ai são os atributos de indexação.
O uso de índices pode aumentar a velocidade das consultas,
create index RG_Funcionário ON funcionario(RG) porém deve-se ter cautela na criação desses índices. Não há
limites em relação a quantidade de índices criados. No
Existem duas razões principais para se usar índices:
entanto sabe-se que eles ocupam espaço em disco e nem
♦ Evita dados duplicados, aumentando a garantia de
sempre otimizam as consultas, pois não se tem o controle
integridade no banco de dados com o uso da cláusula
sobre a maneira pela qual os dados serão acessados.
UNIQUE;

♦ Aumenta a rapidez do banco de dados, criando índices Removendo índices

que sejam convenientes às consultas mais comuns e Para remover índices utiliza-se a instrução DROP INDEX

freqüentes no banco de dados. drop index i

onde i é o nome do índice que se deseja excluir
A cláusula UNIQUE, quando utilizada, não permite que
duas linhas da tabela assumam o mesmo valor no atributo
ou no conjunto de atributos indexados.

Pagina 12
 5
Linguagem de
Manipulação de Dados
Aluno “Remover todos os alunos da terceira série A”
RA Nome Serie Turma Endereço delete from aluno
112121 Maria Pereira 2 A Rua Pio XII, 23 where serie = 3
123251 José da Silva 3 B Rua Direita, 45 and turma = ‘A’
321233 Rui Barros 1 B Rua Edson, 32
Alteração de registros
453627 Ivo Pitanga 3 A Praça Redonda, 34
Para alterar o valor de um campo de um determinado
Inserção de registros registro ou de registros que obedecem a determinada
Para inserir dados em uma tabela utiliza-se o comando condição utiliza-se a instrução UPDATE.
INSERT INTO onde são especificados os valores de cada
Suponha que o aluno José da Silva (ra=123251) será
campo do novo registro.
transferido para a quarta série.
Suponha que desejamos inserir um aluno com os seguintes update aluno
dados: set serie = 4
where ra = 123251
RA 123251
Nome José da Silva
Suponhamos agora que todos os alunos da terceira série B
Serie 3
Turma B serão transferidos para a quarta série.
Endereco Rua Direita, 45 update aluno
set serie = 4
insert into aluno
where serie = 3
values (123251, ‘José da Silva’, 3, ‘B’,
and turma = ‘B’
‘Rua Direita, 45’)

Consultando os dados
No exemplo acima, os valores são especificados na ordem
O principal comando da Linguagem de Manipulação de
na qual os campos foram definidos na tabela.
dados (DML) é o comando SELECT-FROM-WHERE.
Caso o usuário não se lembrar da ordem dos atributos, é
♦ A cláusula SELECT corresponde à projeção da álgebra
permitido que os atributos sejam especificados como parte
relacional. É usada para listar os campos desejados no
da instrução INSERT.
resultado de uma consulta.
insert into aluno(nome,ra,serie,endereco,turma)
values (‘José da Silva’, 123251, 3, ♦ A cláusula FROM corresponde ao produto cartesiano
‘Rua Direita, 45’, ‘B’)
da álgebra relacional. Na cláusula FROM são listadas
Remoção de registros todas as tabelas a serem utilizadas na consulta.
A remoção de registros de uma tabela é feita através da
♦ A cláusula WHERE corresponde à seleção da álgebra
instrução DELETE.
relacional. Consiste em um predicado (condição)
delete from T envolvendo atributos das tabelas que aparecem na
where P
cláusula FROM.
onde P representa um predicado (condição) e T representa uma
tabela. Uma típica consulta SQL tem a forma:
select A1, A2, A3, ...
“Excluir todos os alunos” from T1, T2, ...
delete from alunos where P
onde Ai representa os atributos, Ti as tabelas envolvidas na
consulta e P um predicado ou condição.
 Linguagem de Manipulação de Dados
“Apresentar os alunos da terceira série” através da utilização da palavra DISTINCT após a cláusula
select Ra, Nome SELECT.
from aluno
select serie select DISTINCT serie
where serie = 3
from aluno from aluno
123251 José da Silva
2 2
453627 Ivo Pitanga
3 3
1 1
A condição (ou predicado) que segue a cláusula WHERE 3
pode conter operadores de comparação
A SQL permite o uso da palavra ALL para especificar
= Igual > maior < Menor
explicitamente que não queremos que as duplicações sejam
<> diferente >= maior ou igual <= menor ou igual
removidas.
e os operadores booleanos AND, OR e NOT.
select ALL serie
“Apresentar o RA e o Nome from aluno
dos alunos da terceira série B” 2
select ra, nome
3
1
from aluno
3
where serie = 3
and turma = ‘B’
Uma vez que a duplicação dos registros resultantes é o
123251 José da Silva
padrão, a utilização da cláusula ALL torna-se opcional.
A cláusula WHERE pode ser omitida e a lista de atributos
Ordenando o resultado de uma consulta
(A1, A2, ...) pode ser substituída por um asterisco (*) para
A linguagem SQL oferece uma maneira de controlar a
selecionar todos os campos de todas as tabelas presentes na
ordem que a resposta de uma consulta será apresentada. A
cláusula FROM.
cláusula ORDER BY permite ordenar o resultado de uma
“Apresentar todos os dados dos alunos” consulta.
select * SELECT A1, A2, ...
from aluno FROM r1, r2, ...
WHERE P
112121 Maria Pereira 2 A Rua Pio XII, 23 ORDER BY A1 [ASC/DESC],
123251 José da Silva 3 B Rua Direita, 45 A2 [ASC/DESC],
321233 Rui Barros 1 B Rua Edson, 32 ...
453627 Ivo Pitanga 3 A Praça Redonda, 34
Onde Ai, após a cláusula ORDER BY, são nomes de atributos
que servirão de parâmetros para o ordenamento do resultado da
“Apresentar todos os dados dos alunos da terceira série” consulta.
select * A cláusula ORDER BY permite ordenar as linhas do
from aluno
resultado da consulta em ordem crescentes ou decrescentes.
where serie = 3
Quanto utilizada, a cláusula ORDER BY sempre deve
123251 José da Silva 3 B Rua Direita, 45
453627 Ivo Pitanga 3 A Praça Redonda, 34 aparecer na última linha da consulta.

As palavras ASC e DESC determinam se a ordenação será

Eliminando resultados duplicados
ascendente ou descendente, respectivamente. Caso nada
Linguagens de consultas formais são baseadas em noções
seja especificado, é assumida a ordenação ascendente
matemáticas de relação. Assim, nunca deveriam aparecer
(ASC).
registros duplicados nos resultados das consultas. Porém,
select distinct serie
como padrão, a linguagem SQL não elimina os registros from aluno
duplicados que possam aparecer no resultado de uma ORDER BY serie

consulta. Todavia, é possível eliminar tais duplicações 1

2
3

Pagina 14
 Linguagem de Manipulação de Dados
“Apresentar a série e o nome do aluno em ordem select nome, serie, turma
decrescente da série e em ordem crescente de nome” from aluno
where serie = 3
select serie, nome
INTERSECT
from aluno
select nome, serie, turma
order by serie DESC, nome ASC
from aluno
3 Ivo Pitanga where turma = ‘B’
3 José da Silva
2 Maria Pereira José da Silva 3 B
1 Rui Barros
Para achar todos os alunos que cursam a segunda ou a
Operações de Conjunto terceira série:
A SQL inclui as operações UNION, INTERSECT e select nome, serie, turma
from aluno
MINUS.
where serie = 2
UNION
“Apresentar o nome dos aluno
select nome, serie, turma
que cursam a terceira série”
from aluno
select nome where serie = 3
from aluno
Maria Pereira 2 A
where serie = 3
José da Silva 3 B
Ivo Pitanga 3 A
“Apresentar o nome dos alunos
que estejam na turma B” Como padrão, a operação UNION elimina as linhas
select nome duplicadas. Para reter duplicações precisamos escrever
from aluno
UNION ALL no lugar de UNION.
where turma = ‘B’
Para encontrar todos os alunos que fazem a terceira série
Para achar todos os alunos que cursam a terceira série ou
mas não são da turma B podemos escrever:
que estejam na turma B podemos utilizar o seguinte
select nome
comando: from aluno
where serie = 3
select nome, serie, turma
minus
from aluno
select nome
where serie = 3
from aluno
UNION
where turma = ‘B’
select nome, serie, turma
from aluno Ivo Pitanga 3 A
where turma = ‘B’

José da Silva 3 B As operações INTERSECT e MINUS eram parte da SQL

Ivo Pitanga 3 A original mas não estão incluídas na versão padrão pois é
Rui Barros 1 B
possível expressar estas operações de uma outra forma.
Para achar todos os alunos que cursam a terceira série e que
são da turma B pode-se fazer:

Pagina 15
 6
Predicados
Cliente select nome, cidade
from emprestimo, cliente
Codigo Decimal(5)
where cliente=cliente.codigo
Nome char(30) and agencia = ‘Ipiranga’
Endereco char(40)
Cidade char(20) A linguagem SQL utiliza conectivos lógicos and, or e not.

Conta Além disso, uma expressão aritmética pode envolver

Numero Decimal(7) qualquer um dos operadores +, -, * e /.

Agencia Decimal(4) A SQL inclui ainda um operador de comparação between
Cliente Decimal(5) para simplificar as cláusulas where que especificam que
Saldo decimal(16,2)
um valor seja menor ou igual a um determinado valor e
Emprestimo maior ou igual a um outro valor. Se desejarmos achar o
Agencia decimal(4)
número das contas com saldo entre 90.000 e 100.000,
Numero decimal(7)
podemos usar a cláusula BETWEEN:
Cliente decimal(5)
select numero
Valor decimal(16,2)
from conta
Agencia where saldo between 90000 and 100000

Código decimal(4)
ao invés de
Cidade char(20)
select numero
Ativos decimal(16,2)
from conta
where saldo >= 90000 and saldo <= 100000
“Apresentar o número da(s) conta(s) e o respectivo saldo
dos clientes que possuem empréstimo”
Da mesma forma, pode-se usar o operador de comparação
select conta.numero, saldo
NOT BETWEEN.
from emprestimos, conta
where emprestimo.cliente = conta.cliente A SQL inclui um operador de substituição de cadeia para
comparações em cadeias de caracteres. Os padrões são
Note que a SQL usa a notação relação.atributo para evitar
descritos usando dois caracteres especiais:
ambigüidade nos casos em que um atributo aparece no
esquema de mais de uma relação. Poderia ter sido escrito ♦ % (por cento) Substitui qualquer subcadeia
conta.saldo em vez de saldo na cláusula SELECT. No ♦ _ (sublinhado) Substitui qualquer caracter
entanto, uma vez que o atributo saldo aparece em apenas Os padrões são sensíveis à forma; isto é, os caracteres
uma das relações referenciadas na cláusula FROM, não há maiúsculos não substituem os caracteres minúsculos, ou
ambigüidade quando escrevemos apenas saldo. vice-versa. Para ilustrar a substituição de padrão, considere
Vamos entender a consulta anterior e considerar um caso os seguintes exemplos:
mais complicado no qual queremos também os clientes com ♦ ‘Jose%’ substitui qualquer cadeia começando com
empréstimos na agência Ipiranga: “Jose”;
“Apresentar o nome e a cidade dos clientes com ♦ ‘%ari%’ substitui qualquer cadeia contendo “ari” como
empréstimo na agência Ipiranga”
uma subcadeia, por exemplo, “Maria”, “Mariana”,
Para escrever esta consulta, devemos utilizar duas restrições
“Itaparica”;
na cláusula WHERE, conectadas pelo operador lógico
♦ ‘_ _ _’ substitui qualquer cadeia com exatamente três
AND.
caracteres;
 Predicados
♦ ‘_ _ _ %’ substitui qualquer cadeia com pelo menos três select cliente
from emprestimo
caracteres.
where agencia = 38
Os padrões são expressos em SQL usando o operador de and cliente in
(select cliente
comparação LIKE. Considere a consulta:
from conta
where agencia = 38 )
“Apresentar os nomes de todos os clientes cujas ruas
possuem a subcadeia ‘Lima’ “
É possível escrever a mesma consulta de diversas formas
select nome
em SQL. Isto é benéfico, uma vez que permite a um usuário
from cliente
where endereco like “%Lima%” pensar sobre a consulta no modo que lhe aparenta ser mais
natural.
Para que os padrões possam incluir os caracteres especiais
% e _, a linguagem SQL permite a especificação de um No exemplo anterior, testamos membros de uma relação de

caractere de escape, representado por um caracter definido um atributo. É possível testar um membro em uma relação

pelo usuário, por exemplo “\” (barra invertida). Assim, o arbitrária.

select cliente
caracter após “\” é interpretado como um literal, não como
from emprestimo
um caracter especial. Por exemplo: where agencia = 38
and agencia, cliente in
Like ‘ab\%cd%’ escape ‘\’ Cadeias de caracteres que
começam com “ab%cd”; (select agencia, cliente
from conta)
Like ‘ab\\%cd%’ escape ‘\’ Cadeias de caracteres que
começam com “ab\cd”.
Ilustramos agora o uso de NOT numa construção.
A SQL permite a procura por não-substituição em vez de
substituição usando o operador de comparação NOT LIKE. “Apresentar todos os clientes que têm uma conta na
agência 38, mas NÃO possuem um empréstimo nessa
mesma agência”
Membros de Conjuntos
select cliente
O conectivo IN testa os membros de conjunto, onde o
from conta
conjunto é uma coleção de valores produzidos por uma where agencia = 38
and cliente not in
cláusula SELECT. O conectivo NOT IN testa a ausência
(select cliente
dos membros de um conjunto. from emprestimo
where agencia = 38)
“Apresentar os clientes que possuem conta e empréstimo
na agência 38”
Começamos localizando todos os possuidores de conta na
Variáveis Tupla
agencia 38: Uma variável tupla na linguagem SQL precisa estar
associada à uma relação particular. As variáveis tupla são
select cliente
from conta definidas na cláusula FROM.
where agencia = 38
“Apresentar o nome e a cidade dos clientes que possuem
Precisamos então encontrar aqueles clientes que são empréstimo”
solicitadores de empréstimo da agência 38 e que aparece na select C.nome, C.cidade
from emprestimo E, cliente C
lista de possuidores de contas da agência 38. Fazemos isso
where E.cliente = C.codigo
embutindo a subconsulta acima em outro SELECT.
Uma variável tupla é definida na cláusula FROM depois do
nome da relação à qual está associada, separada por um ou
mais espaços.

Variáveis tupla definidas em uma consulta são válidas

também nas subconsultas de nível inferior. Variáveis tupla

Página 17
 Predicados
definidas em uma subconsulta não são “enxergadas” por “Quais os clientes que possuem conta em alguma agência
onde o cliente de código 12345 tem conta”
subconsultas de nível superior. Se uma variável tupla é
select distinct C.cliente
definida tanto localmente em uma subconsulta quanto
from conta C, conta T
globalmente em uma consulta, a definição local prevalece. where C.cliente = 12345
Isto é análogo às regras usuais de alcance usadas para and C.agencia = T.agencia

variáveis em linguagens de programação. Quando Observe que não podemos usar a notação contas.agencia,
escrevemos expressões da forma relação.atributo, o nome uma vez que não estaria claro qual referência a contas é a
da relação é, de fato, uma variável tupla definida desejada.
implicitamente.
Um modo alternativo para expressar esta consulta é
As variáveis tupla são mais úteis para comparação de duas select distinct cliente
tuplas na mesma relação. from conta
where agencia in
(select agencia
from conta
where cliente = 12345)

Página 18
 7
Comparação de Conjuntos
“Apresentar os nomes das agências que possuem ativos select nome
maior do que alguma agência localizada em São Paulo” from agencia
where ativos >all
select distinct T.nome
(select ativos
from agencia T, agencia S
from agencia
where T.ativos > S.ativos and
where cidade = “Sao Paulo”)
S.cidade = ‘Sao Paulo’

Uma vez que isto é uma comparação “maior que”, não Como na cláusula some, a SQL permite comparações <all,

podemos escrever a expressão usando a construção in. <=all, >=all, =all e <>all.

A SQL oferece um estilo alternativo para escrever a As construções in, >some, >all, etc; nos permitem testar um

consulta acima. A frase “maior do que algum” é valor simples contra membros de um conjunto. Uma vez

representado na SQL por >some. Esta construção permite que SELECT gera um conjunto de tuplas, podemos querer

reescrever a consulta em uma forma que se assemelha comparar conjuntos para determinar se um conjunto contém

intimamente à fórmula da nossa consulta em português. todos os membros de algum outro conjunto. Tais
comparações são feitas na SQL usando as construções
select nome
from agencia contains e not contains.
where ativos >some
(select ativos “Apresentar o código dos clientes que possuem conta em
from agencia todas as agências localizadas em São Paulo”.
where cidade = ‘Sao Paulo’)
Para cada cliente, precisamos ver se o conjunto de todas as

A subconsulta agências na qual um cliente possui uma conta contém o

(select ativos conjunto de todas as agências em São Paulo.

from agencia select distinct S.cliente
where cidade = ‘Sao Paulo’) from conta S
where (select T.agencia
gera o conjunto de todos valores de ativos das agências em from conta T
where S.cliente = T.cliente)
São Paulo: A comparação >some na cláusula WHERE do
contains
SELECT externo é verdadeira se o valor do atributo ativos (select agencia
da tupla for maior do que pelo menos um membro do from agencia
where cidade = ‘Sao Paulo’)
conjunto de todos os valores de ativos das agências de Sao
Paulo. A subconsulta

A SQL também permite comparações <some, <=some, (select agencia

from agencia
>=some, =some e <>some. Observe que =some é idêntico where cidade = ‘Sao Paulo’)
a in. Uma cláusula similar à cláusula some é a cláusula any,
encontra todas as agências em São Paulo.
que possui também todas as variações existentes na
cláusula some: <any, <=any, >=any, >any, =any, <>any. A subconsulta
(select T.agencia
“Apresentar os nomes das agências que possuem ativos from conta T
maiores do que qualquer (todas) uma das agências de São where S.cliente = T.cliente)
Paulo”
A construção >all corresponde à frase “maior do que encontra todas as agências nas quais o cliente
todos”. Usando esta construção, escrevemos a consulta S.nome_cliente tem uma conta. Assim, o SELECT externo
como segue: pega cada cliente e testa se o conjunto das agências onde
 Comparação de Conjuntos
ele possui conta contém o conjunto de todas as agências em “Apresentar os clientes que possuem conta em todas as
agências localizadas em São Paulo”
São Paulo.
Usando uma construção minus, podemos escrever a
A construção contains não aparece no padrão ANSI. Uma
consulta da seguinte forma:
boa razão para isso é que o processamento da construção
select distinct S.nome_cliente
contains é extremamente custoso. from contas S
where not exists ( ( select nome_agencia
Testando Relações Vazias from agencias
where cidade = ‘Sao Paulo’)
A SQL inclui um recurso para testar se uma subconsulta
minus
tem alguma tupla em seus resultados. A construção exists ( select T.agencia
retorna o valor true se o resultado da subconsulta não é from contas T
where S.nome_cliente =
vazio. T.nome_cliente ) )

“Apresentar os clientes que possuem uma conta e um A subconsulta

empréstimo na agência 17”
( ( select nome_agencia
select nome
from agencias
from cliente
where cidade = ‘Sao Paulo’)
where exists (select *
from conta
encontra todas as agências em São Paulo.
where conta.cliente = cliente.codigo
and agencia = 17) A subconsulta
and exists (select *
( select T.agencia
from emprestimo
from contas T
where emprestimos.cliente =
where S.nome_cliente =
clientes.código
T.nome_cliente ) )
and agencia = 17)

A primeira subconsulta exists testa se o cliente tem uma encontra todas as agências na qual S.nome_cliente possui

conta na agência Ipiranga. A segunda subconsulta exists uma conta. Assim, o SELECT externo pega cada cliente e

testa se o cliente tem um empréstimo na agência Ipiranga. testa se o conjunto de todas as agências de São Paulo menos
o conjunto de todas as agências nas quais o cliente tem uma
A não-existência de tuplas em uma subconsulta pode ser
conta, é vazio.
testada usando a construção not exists.

“Apresentar os clientes que possuem conta na agência

Ipiranga mas não possuem empréstimo nesta agência”
select nome_cliente
from clientes
where exists (select *
from contas
where contas.nome_cliente =
clientes.nome_cliente and
nome_agencia = ‘Ipiranga’)
and not exists (select *
from emprestimos
where emprestimos.nome_cliente =
clientes.nome_cliente and
nome_agencia = ‘Ipiranga’)

Página 20
 8
Funções Agregadas
Clientes “Apresentar o saldo médio de conta em cada agência”
Nome_cliente char(30) select nome_agencia, avg(saldo)
Endereco char(40) from contas
Cidade char(20) group by agencia

Contas A retenção de duplicatas é importante na computação da

Numero_conta decimal(7) média. Suponha que os saldos de conta na agência Ipiranga
Nome_agencia char(20)
sejam 1.000, 2.000, 3.000 e 1.000. O saldo médio é 7.000/4
Nome_cliente char(30)
= 1.666,67. Se as duplicações fossem eliminadas, teríamos
Saldo decimal(16,2)
uma resposta errada (6.000/3 = 2.000).
Emprestimos
Nome_agencia char(20) A cláusula group by conceitualmente rearranja a tabela
Numero decimal(7) especificada após a cláusula FROM em partições ou
Nome_cliente char(30) grupos, de tal forma que dentro de qualquer dos grupos
Valor decimal(16,2)
todas as linhas tenham o mesmo valor do atributo
Agencias especificado no group by.
Nome_agencia char(20)
Existem casos nos quais as duplicações precisam ser
Cidade char(20)
Ativos decimal(16,2)
eliminadas antes de uma função agregada ser computada.
Se desejarmos eliminar duplicações, usamos a palavra
chave distinct na expressão agregada.
A SQL oferece a habilidade para computar funções em
grupos de registros usando a cláusula group by. O atributo “Encontre o número de correntistas de cada agência”
ou atributos utilizados na cláusula group by são usados Neste caso, um correntista é contado uma só vez,
para formar grupos. Registros com o mesmo valor em todos independentemente do número de contas que ele possa ter.
os atributos na cláusula group by são colocados em um select nome_agencia,count(distinct nome_cliente)
from contas
grupo. A SQL inclui funções para computar:
group by agencia
A linguagem SQL possui algumas funções específicas para
Às vezes é útil definir uma condição que se aplique a
cálculos em grupos de tuplas:
grupos em vez de registros. Por exemplo, podemos estar
♦ média: avg
interessados apenas em agências nas quais a média dos
♦ mínimo: min saldos é maior do que 1.200. Esta condição não se aplica a
♦ máximo: max registros simples, mas sim a cada grupo construído pela

♦ total: sum cláusula group by. Para expressar tal consulta usamos a
cláusula having. Os predicados na cláusula having são
♦ contar: count
aplicados depois da formação dos grupos, para que funções
As operações como a avg são chamadas funções agregadas
agregadas possam ser usadas.
porque operam em agregações de tuplas. O resultado de
select nome_agencia, avg(saldo)
uma função agregada é um valor único. Para ilustrar, from contas

considere a consulta: group by agencia

having avg(saldo) > 1200
 Funções Agregadas
As funções agregadas não podem ser compostas em SQL. “Apresentar a média dos saldos dos correntistas que
vivem em São Paulo e possuem pelo menos três contas”
Isto significa que qualquer tentativa de usar max(avg(...))
select avg(saldo)
não será permitida. Por outro lado, nossa estratégia é achar
from contas, clientes
aquelas filiais para as quais a média de saldo é maior ou where contas.nome_cliente =
clientes.nome_cliente
igual a todas as médias de saldo.
and cidade = ‘Sao Paulo’
group by contas.nome_cliente
“Apresentar o nome das agências com a maior média de
having count(distinct numero_conta) >= 3
saldos”
select nome_agencia A versão ANSI da SQL requer que count seja usada apenas
from contas
group by agencia
como count(*) ou count(distinct...). É válido usar distinct
having avg(saldo) >=all (select avg(saldo) com max e min mesmo que o resultado não se altere. A
from contas
palavra-chave all pode ser usada no lugar de distinct para
group by agencia)
permitir duplicações, mas, uma vez que all é o default, não
Às vezes desejamos tratar a relação inteira como um grupo existe necessidade de utilizá-lo.
simples. Em tais casos, não usamos a cláusula group by.
A SQL inclui as operações da álgebra relacional
“Apresentar a média dos saldos” fundamental. O produto cartesiano é representado pela
select avg(saldo) cláusula FROM. A projeção é executada na cláusula
from contas
SELECT. Os predicados de seleção da álgebra relacional
A função agregada count é usada freqüentemente para são representados nas cláusulas WHERE. A álgebra
contar o número de tuplas numa relação. A notação para relacional e a SQL incluem a união e a diferença. A SQL
isto é count(*). Assim para achar o número de tuplas da permite resultados intermediários para ser guardados em
relação cliente, escrevemos: relações temporárias. Assim, podemos codificar qualquer

select count(*) expressão da álgebra relacional na SQL.

from clientes
A SQL oferece uma rica coleção de recursos, abrangendo
Se uma cláusula WHERE e uma cláusula having aparecem funções agregadas, ordenação de tuplas e outras
em uma mesma consulta, o predicado na cláusula WHERE capacidades não incluídas nas linguagens formais de
é aplicado primeiro. As tuplas que satisfazem o predicado consulta. Assim, a SQL é mais poderosa do que a álgebra
WHERE são então agrupadas po uma cláusula group by. A relacional.
cláusula having é então aplicada a cada grupo. Os grupos Muitas versões da SQL permitem que consultas SQL sejam
que satisfazem o predicado da cláusula having são usados submetidas a partir de um programa escrito em uma
pela cláusula SELECT para gerar tuplas do resultado da linguagem de uso genérico como Pascal, PL/I, Fortran, C
consulta. Se não houver uma cláusula having, todo o ou Cobol. Esta forma da SQL estende ainda mais a
conjunto de tuplas que satisfazem a cláusula WHERE é habilidade do programador de manipular o banco de dados.
tratado como um grupo simples.

Página 22
 9
Visões
Uma visão (view) é uma tabela virtual cujo conteúdo é
definido por uma consulta ao banco de dados. A visão não é create view todos_clientes as
(select nome_agencia, nome_cliente
uma tabela física, mas um conjunto de instruções que from contas)
retorna um conjunto de dados. Uma visão pode ser union
(select nome_agencia, nome_cliente
composta por algumas colunas de uma única tabela ou por from emprestimos)
colunas de várias tabelas.
Nomes de visões aparecem em qualquer lugar que um nome
O uso de visões é particularmente útil quando se deseja dar
de relação possa aparecer. Usando a visão todos_clientes,
foco a um determinado tipo de informação mantida pelo
podemos achar todos os clientes da agência Ipiranga:
banco de dados. Imagine um banco de dados corporativo
select nome_cliente
que é acessado por usuários de vários departamentos. As from todos_clientes
informações que a equipe de vendas manipula certamente where nome_agencia = ‘Ipiranga’

são diferentes daquelas do departamento de faturamento.

Uma vez que a SQL permite a um nome de visão aparecer
Por meio de visões é possível oferecer ao usuário apenas as
em qualquer lugar em que o nome de uma relação aparece,
informações que necessita, não importando se elas são
podemos escrever:
oriundas de uma ou várias tabelas do banco de dados.
create view emprestimos_info as
As visões permitem que diferentes usuários vejas as select nome_agencia, numero, nome_cliente
from emprestimos
mesmas informações sob um ponto de vista diferente. As
visões permitem que informações sejam combinadas par insert into emprestimos_info
values (‘Ipiranga’, 17, ‘Paulo Farias’)
atender a um determinado usuário e até mesmo serem
exportadas para outros aplicativos. Esta inserção é na verdade uma inserção na relação
Uma das maiores vantagens de se criar uma visão é facilitar empréstimo, uma vez que empréstimo é a relação a partir da
as consultas dos usuários que só utilizam determinadas qual a visão emprestimo_info foi construída. Devemos,
informações, diminuindo assim o tamanho e a entretanto, ter algum valor para quantia. Este valor é um
complexidade dos comandos SELECT. valor nulo. Assim, o insert acima resulta na inserção da
tupla
Uma outra vantagem de utilizar visões é quanto a
segurança, pois evita que usuários possam acessar dados de (‘Ipiranga’, 17, ‘Paulo Farias’)

uma tabela que podem ser confidenciais. na relação emprestimos.

Uma visão é definida na SQL usando o comando CREATE
VIEW. Para definir uma visão precisamos dar à visão um
nome e definir a consulta que a processa. A forma do
comando CREATE VIEW é:
create view v as <expressão de consulta>
<expressão de consulta> é qualquer expressão de consulta
válida. O nome da visão é definido por v.
 1 0
Permissões
Uma importante tarefa que deve ser realizada pelo
Atribuindo Privilégios
administrador de banco de dados é a criação de contas de
O comando GRANT permite atribuir privilégios a um
usuários. Qualquer pessoa que quiser acessar um banco de
usuário (ou grupo de usuários). Os privilégios podem ser:
dados precisa ser previamente cadastrada como usuário do
SELECT, INSERT, UPDATE, DELETE ou ALL
banco de dados e ter estabelecido para ela privilégios com
PRIVILEGES. Os objetos que geralmente se concedem
relação às tarefas que poderão ser executadas no banco de
privilégios são tabelas e visões.
dados.

Controlar o aceso ao banco de dados é uma das principais GRANT privilégio/ALL PRIVILEGES
ON objeto
tarefas que um administrador tem. Para realizar esse TO usuário1, usuário2,... /PUBLIC
[WITH GRANT OPTION]
controle, os bancos de dados contam com um mecanismo
privilégio nome do privilégio
que permite cadastrar um usuário. Cada usuário cadastrado
ALL PRIVILEGES todos os privilégios
recebe uma senha de aceso que precisa ser fornecida em
Objeto Geralmente tabela ou visão
diversas situações.
Usuário um determinado usuário
PUBLIC todos os usuários
Privilégios
WITH GRANT OPTION parâmetro opcional que permite
Um privilégio é uma autorização para que o usuário acesse que o usuário que recebe o privilégio possa concede-lo a outros
e manipule um objeto de banco de dados de uma certa usuários

forma. Por exemplo, um usuário pode ter o privilégio de

selecionar tabelas, porém não pode modifica-las. Outro Revogando um Privilégio
usuário pode tanto ler como alterar os dados ou até mesmo Assim como você concedeu um privilégio, também pode

a estrutura das tabelas e outros objetos. retirá-lo. O comando SQL responsável por essa tarefa é o
comando REVOKE.
Existem dois tipos de privilégio: os privilégios de sistema e
os privilégios de objetos. REVOKE [GRANT OPTION FOR] privilégio
ON objeto
Um privilégio de sistema é o direito ou permissão de FROM usuário1, usuário2,.../PUBLIC
executar uma ação em um tipo específico de objeto de GRANT OPTION FOR parâmetro opcional que retirar a
permissão de repassar o privilégio
banco de dados.
privilégio nome do privilégio
O privilégio de objeto é o direito de executar uma
ALL PRIVILEGES todos os privilégios
determinada ação em um objeto específico, como o direito
Objeto Geralmente tabela ou visão
de incluir um registro em uma determinada tabela. Os
Usuário um determinado usuário
privilégios de objeto não se aplicam a todos os objetos de PUBLIC Todos os usuários
banco de dados.

Quando um usuário cria um objeto como uma tabela, ela só

pode ser visualizada pelo próprio usuário que a criou. Para
que outro usuário tenha acesso a ela, é necessário que o
proprietário da tabela conceda privilégios para o usuário
que irá acessar a tabela.
 1 1
A Sintaxe da linguagem SQL
 GBC043 – Sistemas de Banco de Dados
Modelo de Entidade-Relacionamento (ER)
Projeto de BD – Uma Visão Panorâmica
Projeto Conceitual

• Modelagem de dados em alto nível

• Foco no domínio do problema e não na solução
• Elementos básicos
 Modelar os conceitos do mundo real
 Modelar as características dos conceitos
 Modelar os relacionamentos entre conceitos
Modelo de Entidade-Relacionamento (MER)

• O MER, ou simplesmente ER, foi desenvolvido com o

objetivo de facilitar o projeto de banco de dados por
meio de um modelo independente de implementação e
de fácil compreensão por parte do usuário
• Conceitos básicos:
– Entidade, Tipo Entidade e Conjunto de Entidades
– Relacionamento e Conjunto de Relacionamentos
– Atributos
• Def. O Diagrama ER-DER é uma representação gráfica
de Entidades, Atributos e Relacionamentos que
modelam um Esquema de Banco de Dados
DER – Um exemplo – Company Database
ER - Entidade

Def ENTIDADE é um conceito do mundo real com

existência independente.
Exemplo: empregado, projeto, curso
Obs: empregado é um conceito físico;
curso é um conceito abstrato

• o retângulo representa Tipo Entidade

• O tipo Empregado representa um Conjunto de
Entidades, ou seja, todas as instâncias no BD
ER - Atributo
Def. ATRIBUTO é uma propriedade da entidade
• Exemplo: código, nome, créditos

Um atributo no DER é representado por uma elipse ligada ao

Tipo Entidade.
Existem vários tipos de atributos...
ER – Atributo Simples
Def. ATRIBUTO SIMPLES ou ATÔMICO é um atributo
básico e indivisível.
• Exemplos: sexo, cpf
ER – Atributo Composto
Def. ATRIBUTO COMPOSTO é um atributo que pode ser
dividido em partes com significados diferentes
Exemplo: employee.name, pessoa.endereço
ER – Hierarquia de Atributos
Um Atributo Composto pode formar uma hierarquia
 ER – Atributo Multivalorado e Monovalorado
Def. ATRIBUTO MULTIVALORADO é um atributo que
possui um conjunto de valores para uma mesma entidade
Exemplo: telefone

Def.
ATRIBUTO MONOVALORADO
é um atributo que possui um único
valor para uma mesma entidade
Exemplo: nome

OBS: no DER um Atributo Multivalorado é representado por

uma elipse com contorno em linha dupla
ER – Atributo Chave
Def. ATRIBUTO CHAVE é um atributo cujos valores são
distintos p/ instâncias distintas de um Conjunto Entidades
Exemplos: disciplina.código, turma.sigla, turma.codigo

OBS: no DER um Atributo Chave é representado por um

sublinhado em seu nome. Observe que uma entidade pode ter
mais de um atributo chave.
ER – Atributo Derivado e Armazenado
Def. ATRIBUTO DERIVADO é um tipo de atributo cujo
valor pode ser obtido de outros atributos ou
relacionamentos. Diante disso não precisa ser armazenado.
Ex: pessoa.idade, departamento.numerodeempregados

OBS: no DER um Atributo Derivado é representado por uma

elipse com contorno em linha tracejada. O ATRIBUTO
ARMAZENADO é aquele cujo valor será fisicamente no BD.
 Exercício–Entidades/Atributos de EMPRESA
Elabore uma representação para entidades e atributos do BD EMPRESA
que deve armazenar dados de funcionários, departamentos e projetos
de uma empresa. Cada departamento tem um nome exclusivo, um
número exclusivo e um funcionário que o gerencia a partir de uma
data. Um departamento pode estar em vários locais e controla uma
série de projetos. Cada projeto tem um nome exclusivo, um número
exclusivo e um local exclusivo. O funcionário tem um nome, CPF,
endereço, salário, sexo, data de nascimento, está lotado em um
departamento, mas pode trabalhar em vários projetos. Registraremos o
número de horas que o funcionário trabalha em um determinado
projeto. Registraremos também o supervisor do funcionário, que é
outro funcionário. Os dependentes dos funcionários serão registrados
com nome, sexo, data de nascimento e parentesco com o funcionário.
ER – Relacionamento
Def. RELACIONAMENTO é uma associação entre entidades
que deve ser definido quando um tipo entidade se refere a
outro tipo entidade.

Um relacionamento no DER é representado por um losango

ligado às entidades.
Existem vários tipos de relacionamentos
ER – Papéis em relacionamentos
Def. PAPEL em um
relacionamento define
como a entidade
participa do mesmo
Exemplo:
Supervisor
Supervisionado
Muitas vezes o papel está
implícito, mas é
necessária sua indicação
em auto-relacionamentos
ER – Cardinalidade em Relacionamentos
Def. CARDINALIDADE de relacionamento é a quantidade
máxima de ocorrência de entidades que podem estar
associadas a uma ocorrência de outra entidade

No DER definimos a cardinalidade como 1 ou N, este último

indicando várias entidades associadas a uma outra entidade.
ER – Partitipação em Relacionamentos
Def. PARTICIPAÇÃO TOTAL de uma
entidade em um relacionamento
indica que qualquer instância da
entidade necessariamente participa
de um relacionamento
Exemplo: PROJECT necessariamente
participa do relacionameto
CONTROLS
No DER um relacionamento com
participação total é indicado por
meio de uma linha dupla. Quando
não é total, chamamos de
Partcipação Parcial
 ER – Entidade Fraca
Def. ENTIDADE FRACA é aquela que não possui atributo chave e é
identificada por meio de um relacionamento total com pelo menos um tipo
Entidade Forte.
Ex: Dependente/Entidade Fraca; Funcionário/Entidade Forte

No DER, um Tipo Entidade Fraca é representado por meio de retângulo com

contorno em linha dupla. O relacionamento total com pelo menos uma entidade
forte é denotado por um losângulo com contorno em linha dupla. A “chave local”
é denotada por sublinhado pontilhado. A chave de uma instância de uma entidade
fraca é um atributo composto pela chave da entidade forte mais a sua “chave
local”
ER - Exemplo
ER:
RESUMO DA
NOTAÇÃO

UFU/FACOM Página 22
ER – Notação alternativa (min, max)
 ER – Grau de Tipo-Relacionamentos
Def. GRAU DE UM TIPO-RELACIONAMENTO é o
número de tipos de entidade que participam.
Ex: relacionamentos de grau 2 (binário) e 3 (ternário)

OBS: No DER um tipo-relacionamento de grau n tem n arcos

no diagrama
ER – Relacionamentos binário/ternário
Um relacionamento ternário é diferente de três
relacionamentos binários (Figura (a) e (b))....
ER – Alternativa para relacionamento ternário
... , mas uma alternativa à representação ternária é usar uma
entidade fraca e três relacionamentos binários Figura (c)
ER Estendido – EER

• Introduz semântica adicional ao ER

• Entidades do ER podem representar:
 CLASSE
 SUBCLASSE
 SUPERCLASSE
• HERANÇA:
 subclasses herdam atributos da superclasse
EER – Especialização/ Generalização
• ESPECIALIZAÇÃO:
 definir sub-classes à partir da super-classe
• GENERALIZAÇÃO:
 definir super-classe à partir de sub-classes
EER – Ex. Especialização/ Generalização

• Cada entidade do Conjunto de Entidades das subclasses

também é um Empregado
• OBS: a notação será discutida em seguida
EER – Herança de Relacionamentos
• Além dos atributos, as subclasses herdam os
relacionamentos das superclasses
• Uma instância da superclasse pode ser instância de zero,
uma ou mais subclasses, dependendo do critério de
especialização/generalização
EER – Ex. Especialização/Generalização
EER – Subclassses mutuamente exclusivas
Critério de Especialização/Generalização
 Disjunto: subclasses mutuamente exclusivas, ou seja,
instância da superclasse pode ser, no máximo, instância
de uma das subclasses

OBS: no DER o critério disjunto é indicado pela letra “d” no

relacionamento superclasse/subclasse;
EER – Exemplo subclassses disjuntas
Uma instância de disciplina não pode ser de graduação e pós
graduação
EER – Subclasses sobrepostas
Critérios de Especialização/Generalização
Sobreposto: subclasses se sobrepõesm, ou seja, instância da
superclasse pode ser instância de mais de uma subclasse

OBS: no DER o critério sobreposto é o default ou pode ser

explicitado pela letra “o”
EER – Exemplo de subclasses sobrepostas
Uma instância de pessoa pode praticar mais de um tipo de
esporte
EER – Exemplo de Especialização
EER – Exemplo de Generalização
EER – Especialização definida com atributo
EER – Especialização com sobreposição
EER – Herança múltipla em subclasses
EER –
Herança Múltipla
EER - Categoria

“UNION TYPE” ou CATEGORIA

• União de entidades formando categorias ou clusters
• Em subclasses compartilhadas existem vários
relacionamentos, mas cada um com uma superclasse
• Em união há apenas um relacionamento com mais de uma
superclasse e a subclasse representa um subconjunto da
união de todas as superclasses

No DER denotamos a união com a letra “U” no

relacionamento das superclasses com a subclasse
EER - Agregação
Def. AGREGAÇÃO é um conceito de abstração para a
criação de objetos compostos com base em componentes
• No ER podemos agregar atributos de objetos para
formar um objeto mais complexo
• Podemos representar um relacionamento de agregação
como um relacionamento comum
EER – Agregação – o problema

Como relacionar Entrevista a outra entidade chamada

Oferta_de_Emprego?
EER –Agregação – 1a abordagem equivocada

Nem toda Entrevista gera uma Oferta_de_Emprego. Logo não

é correto modelar entrevista como um relacionamento.
EER– Agregação – 2a abordagem equivocada

O ER não permite relacionamento entre relacionamentos

(alguna autores definem diagramas ER que permitem)
EER – Abordagem baseada em Agregação

Define-se então um objeto composto, ou Entidade Agregada,

mas esta última também não é usual em ER
EER – Abordagem com Entidade_Fraca

Esta é abordagem recomendade por [EN]

Um Exemplo de EER
Projeto Conceitual - UML

Diagrama de classes da UML como alternativa de modelagem

conceitual
UML – Um Exemplo
UML - Especialização/Generalização
Resumo de Projeto Conceitual com ER e EER
• Entidades (fraca)
• Atributos (atômico, composto, multivalorado, derivado,
chave) e domínios
• Relacionamentos
 participação total e parcial
 Cardinalidades (1:1, 1:N, N:M) ou (min, max)
• Especialização e Generalização
 Total e parcial
 Disjunta e sobreposta
 União ou Categoria
Projeto Conceitual – Alternativas de Notação