Fundamentos e Conceitos Sobre Banco de Dados

BANCO DE DADOS
E BI
Fundamentos e Conceitos
sobre Banco de Dados
SISTEMA DE ENSINO
Livro Eletrônico
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
O conteúdo deste livro eletrônico é licenciado para Nome do Concurseiro(a) - 000.000.000-00, vedada, por quaisquer meios e a qualquer título,
a sua reprodução, cópia, divulgação ou distribuição, sujeitando-se aos infratores à responsabilização civil e criminal.
www.grancursosonline.com.br 2 de 74
BANCO DE DADOS E BI
Questões de Concurso..................................................................................................................48
Gabarito............................................................................................................................................ 73
BANCO DE DADOS E BI
Apresentação
Olá, aluno(a), tudo bem?! Espero e torço que sim!
Bem, vamos dar início à nossa jornada de estudos através do curso sobre Banco de Dados
e Business Intelligence (BI), totalmente focado para concursos públicos.
O nosso principal objetivo é abordar conceitos, fundamentos, características e aplicabili-
dade relativos ao assunto Banco de Dados e BI na forma de teoria e exercícios comentados,
sendo este último um grande aliado que conduzirá você rumo à aprovação, pois possibilitará
a rápida assimilação do conteúdo de forma prática e focada no assunto, porém isso não quer
dizer que o estudo prévio teórico seja menos importante, nada disso, muito pelo contrário, o
conhecimento teórico prévio proporcionará a você uma base de conhecimento a qual será la-
pidada, moldada e aperfeiçoada através dos exercícios, pois são eles quem de fato vão definir
se seu conhecimento para o cargo desejado está dentro do nível esperado.
Além da teoria escrita por mim, também citarei, quando necessário, diversos trechos de
diferentes fontes teóricas, tais como os livros do Navathe, Date e Korth, pois estes são os
principais autores utilizados pelas bancas de concurso na formulação de questões, bem como
para contrapor tentativas de recursos dos candidatos que tentem impugnar alguma ques-
tão da prova.
Sobre mim, sou pernambucano, nascido e criado na minha querida Recife e resido em Bra-
sília-DF desde 2005, sou casado e pai de dois lindos filhos, a Maria Clara e o André, graduado
como Tecnólogo em Gestão de TI e pós-graduado em Políticas Públicas e Gestão Governa-
mental. Trabalho na área de TI desde 1995 e passei por diversos cargos, desde operador de
micro, programador até analista de sistemas. Durante este período pude trabalhar não somen-
te com diversas linguagens de programação (Clipper, Visual Basic, Delphi e Java), bem como
com diferentes Sistemas Gerenciadores de Banco de Dados, tais como MySQL, PostgreSQL,
SQLServer, DB2 e Oracle. Estou no serviço público federal desde 2009, sendo parte deles na
Fundação Nacional de Saúde – FUNASA, onde fiquei apenas 8 meses trabalhando no cargo de
Analista de Sistemas, atuando na área de processos, depois fui nomeado pelo Ministério do
Planejamento, Orçamento e Gestão – MPOG, atual Ministério da Economia, para o cargo de
Analista em TI, onde estou até o momento e tive a oportunidade de exercer minhas atividades
de forma descentralizada na Escola Nacional de Administração Pública – ENAP e no Ministério
da Justiça e Segurança Pública – MJSP, onde estou atualmente. Durante este período como
Analista em TI participei de atividades e projetos utilizando banco de dados multidimensionais,
tais como o DW do Comprasnet e a primeira versão do Portal das Compras Públicas, utilizando
QlikView como ferramenta de Data Discovery e atualmente estou voltando meus estudos e
conhecimentos para área de Ciência de Dados.
Desde 2014 estou lecionando conteúdo sobre Banco de Dados e BI para concursos públi-
cos, buscando dividir não somente o conhecimento na atividade de TI, como também as estra-
tégias de preparação para conquista da tão sonhada vaga no serviço público. Na minha vida de con-
BANCO DE DADOS E BI
curseiro consegui diversas classificações e aprovações, dentre elas: TST 2008 (classificado),
TJDFT 2008(classificado), STF 2008 (classificado), DER/DF 2009 (classificado), CAESB 2009
(classificado), FUNASA 2009 (nomeado), MPOG (Ministério da Economia) 2009 (nomeado).
Já falei muito sobre mim, agora vamos ao que interessa, let’s go!
Sobre a Banca
Neste curso o conteúdo terá como parte prática a resolução de diversas questões da ban-
ca CESPE/Cebraspe.
Eu particularmente me enquadro dentro do rol de pessoas que gostam da banca CESPE/
Cebraspe, pois apesar da sua forma “cruel” de pontuação, ela presa muito pelo entendimento e
não muito pela “decoreba”, além do fato de que se o candidato resolver muitas questões, logo
perceberá quais são os “peguinhas” que banca adora usar e repetir.
Metodologia das Aulas
O curso será todo baseado em teoria e questões comentadas, focadas na banca CES-
PE/Cebraspe.
O conhecimento prévio sobre o assunto ajudará muito na compreensão dos comentários,
porém sua ausência não comprometerá o entendimento dos comentários das questões.
Durante a aula disponibilizarei mapas mentais e/ou esquemas, bem como resumos, para
ajudar no processo de revisão da aula.
Todos os comentários terão por base as tendências de cobrança da banca, procure valo-
rizar cada comentário a fim de que na hora da prova possa facilmente lembrar e “partir para
o abraço”.
Durante a sequência de questões você perceberá que na medida em que avanço nas ques-
tões e consequentemente no assunto, também darei alguns “passos para trás” trazendo algu-
ma questão na sequência que se refira a um assunto visto em algumas questões respondidas
anteriormente. Isso é de propósito, pois é importante a sistemática da repetição, não digo a
repetição da mesma questão, mas do assunto abordado nela, pois quanto mais “maduro” o
assunto fique em mente, melhor para o candidato no momento da prova.
Este formato de aula textual procura seguir um perfil mais informal do que o de um livro es-
crito sobre o assunto, isso porque tentamos, ao máximo, trazer para o texto o mesmo cenário
de uma sala de aula, ou seja, com algumas informalidades e descontrações, porém preservan-
do o principal foco que é o assunto em questão e, lógico, a sua aprovação.
Tente dividir bem o tempo de estudos de acordo com o conteúdo programático, pois assim
será possível prever quando estará concluindo cada etapa e já podendo iniciar o processo de
repetição com base em revisões e resoluções de mais questões, chegando assim no dia da
prova com tranquilidade para assinalar corretamente as questões e garantir a vitória.
BANCO DE DADOS E BI
Cronograma das Aulas
Aula Título da Aula Conteúdo do Edital
Fundamentos e conceitos sobre

Banco de Dados e Sistemas Banco de Dados: Arquitetura e
01 Gerenciadores de Banco de Dados Estrutura
– SGBD
Banco de Dados: Modelo Entidade-

02 Teoria de SGDBs – Parte 1
Relacionamento
03 Teoria de SGDBs – Parte 2 Banco de Dados: Modelo Relacional
04 Teoria de SGDBs – Parte 3 Banco de Dados: Linguagem SQL
05 Business Intelligence I – Parte 1 Conceitos de Data Warehouse
06 Business Intelligence I – Parte 2 Conceitos de Datamining
Administração de Banco de Dados

Tuning em Banco de Dados
07 Administração de Banco de Dados Segurança de Banco de Dados
Teoria e políticas de backup e
recuperação de dados
BANCO DE DADOS E BI
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!
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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á?!
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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:
BANCO DE DADOS E BI
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:
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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.
Figura 8: C.J. Date – Modelo em Rede

BANCO DE DADOS E BI
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;
BANCO DE DADOS E BI
• 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.
Figura 9: NoSQL – Modelo Chave-valor

BANCO DE DADOS E BI
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:
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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 é
BANCO DE DADOS E BI
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,
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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!
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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:
BANCO DE DADOS E BI
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:
BANCO DE DADOS E BI
− 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.
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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.
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
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
BANCO DE DADOS E BI
QUESTÕES DE CONCURSO
001. (CEBRASPE/CESPE/TJ-AM/ASSISTENTE JUDICIÁRIO/2019) Acerca de sistema ge-
renciador de banco de dados, do tuning e da segurança em banco de dados, julgue os itens
subsequentes.
Uma das vantagens de utilizar sistema gerenciador de banco de dados é o fato de ele reali-
zar o controle da redundância de dados, o que impede a ocorrência de inconsistências entre
os arquivos.
A utilização de um SGBD ao invés de arquivos redundantes, especializados em aplicações,

onde para se conseguir obter o mesmo dado em uma organização teria que replicar estes
mesmos dados em diferentes arquivos, o que poderia gerar inconsistências de dados entre os
arquivos, trouxe uma série de vantagens, apresentando uma estrutura onde há uma separação
bem definida entre o que é aplicação e base de dados.
Esta replicação de arquivos, pode ocasionar problemas diversos, quando não controlada, como
por exemplo: mesmos dados com valores diferentes, duplicação de esforços para cadastro,
uso demasiado de espaço para armazenamento.
Nem sempre a redundância é um problema, pois se feita de forma controlada, pode aumentar
a eficiência nas consultas dos dados.
Certo.
002. (CEBRASPE/CESPE/IPHAN/ANALISTA/2018/Q1002575) Acerca da abordagem rela-

cional, da normalização e do SGBD, entre outros conceitos relativos a banco de dados, julgue
os itens a seguir.
Orientado a objetos, relacional, em rede e hierárquico são modelos de SGBD que definem a
forma como os dados são armazenados no banco de dados.
Os SGBDs ao longo do tempo foram evoluindo e apresentando diferentes características e isso

inclui a forma como cada um trabalha no armazenamento de dados, vejamos abaixo uma linha
do tempo com os diferentes SGBDs mais cobrados nas questões de concursos:
• Modelo Hierárquico (Década de 60): Os dados eram organizados formando uma hie-
rarquia, semelhante a uma árvore de dados, 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;
• Modelo em Rede (Década de 60): Uma extensão do modelo hierárquico, sendo as rela-
ções de dados representadas por grafos bidirecionais;
BANCO DE DADOS E BI
• Modelo Relacional (Década de 70): Devido a inflexibilidade dos modelos anteriores, no

tocante 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 programa, dados de um lado e estrutura física do outro. Os dados são armaze-
nados 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 da-
dos, bem como criação da estrutura 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 exis-
tê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 co-
nhecida previamente, 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).
Certo.
003. (CEBRASPE/CESPE/IPHAN/ANALISTA/2018/Q1002572) Acerca da abordagem rela-

cional, da normalização e do SGBD, entre outros conceitos relativos a banco de dados, julgue
os itens a seguir.
Padrões a serem impostos e requisitos contraditórios a serem equilibrados são considerados
como desvantagens da abordagem de banco de dados.
Essa é uma questão fácil, porém perigosa se você resolver analisar de forma superficial, vejamos:
O projeto para elaboração de um banco de dados requer conhecimento prévio sobre o negócio
onde o banco de dados estará inserido e para isso se faz necessário conhecer os requisitos e
definições dos dados em um nível externo, mais próximo do usuário. Com isso, alguns padrões
de dados começam a ser estabelecidos e definidos, porém eles precisam estar bem alinha-
dos com os requisitos e não serem contraditórios, como a questão afirma.
Errado.
004. (CEBRASPE/CESPE/ABIN/OFICIAL TÉCNICO DE INTELIGÊNCIA/2018) A respeito de

sistemas gerenciadores de banco de dados, julgue os próximos itens.
Em um sistema hierárquico, o servidor que recebe pedidos de consultas e distribui essas con-
sultas para origens de dados remotas é denominado servidor hierárquico.
BANCO DE DADOS E BI
Essa é uma questão que derruba o candidato(a) mais audacioso(a), porém não é o seu caso,
vamos analisar.
A questão tenta forçar o conceito de banco de dados no modelo hierárquico com banco de
dados distribuído, apresentando algo que não existe, ou seja, um “servidor hierárquico”, o que
torna a questão inválida.
Os bancos de dados no modelo hierárquico, são organizados formando uma hierarquia, se-
melhante a uma árvore de dados, 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 e isso não tem nada a ver com “servidor hierárquico”.
Um banco de dados distribuído é definido por uma coleção de vários bancos de dados logi-
camente inter-relacionados, distribuídos por uma rede de computadores e possui um Sistema
Gerenciador de Banco de Dados Distribuído (SGBDD), o qual gerencia estes dados numa distri-
buição que fica transparente para o usuário final.
Errado.
005. (CEBRASPE/CESPE/STM/PROGRAMAÇÃO DE SISTEMA/2018/Q958077) Acerca dos

conceitos de normalização de dados e dos modelos de dados, julgue os itens subsequentes.
O modelo conceitual, que reflete uma estrutura simplificada do banco de dados, é responsável
por registrar como os dados estão armazenados no sistema de gerenciamento de banco de
dados (SGBD).
Essa é fácil!
O modelo conceitual, também chamado de alto nível, reflete a necessidade dos dados em um
contexto de fácil compreensão para o usuário, onde ele não precisa conhecer sobre os deta-
lhes do armazenamento destes dados no SGBD. O universo de informações sobre o modelo
conceitual gira em torno das entidades (que podem se transformar em tabelas), dos atributos
(que podem se transformar em colunas) e relacionamentos entre as diferentes entidades. O
modelo conceitual independe da tecnologia que será utilizada, ou seja, do SGBD (se vai ser
MySQL, Oracle, SQL Server, dentre outros do mercado) que será usado para satisfazer a solu-
ção. Resumindo, o modelo conceitual não mostra como os dados estão armazenados.
Errado.
006. (CEBRASPE/CESPE/TC-PB/AUDITOR DE CONTAS PÚBLICAS/2018/Q945208) A res-

peito de SGBDs, assinale a opção correta.
a) Um SGBD, por definição, não é flexível, dada a dificuldade de mudar a estrutura dos dados
quando os requisitos mudam.
BANCO DE DADOS E BI
b) Um SGBD é um software que não prevê as funções de definição, recuperação e alteração de

dados, sendo essa tarefa a função básica de um sistema de banco de dados.
c) A consistência de dados é o princípio que determina a manutenção de determinado dado
em vários arquivos diferentes.
d) Conforme o princípio da atomicidade, caso ocorra erro em determinada transação, todo o
conjunto a ela relacionado será desfeito até o retorno ao estado inicial, como se a transação
nunca tivesse sido executada.
e) O controle de concorrência é o princípio que garante e permite a manipulação, no mesmo
momento, de um mesmo dado por mais de uma pessoa ou um sistema
Vamos por partes!

a) Errada. Uma das vantagens no uso do SGBD é a independência entre dados e aplicação,
ou seja, é possível realizar mudanças na estrutura (esquema) sem afetar a aplicação, o que o
torna flexível.
b) Errada. Outra vantagem existente no SGBD é possibilidade de utilizar uma linguagem capaz
criar estruturas, alterar estruturas e manipular dados, conhecidas como SQL (Structured Query
Language), utilizada para obtenção de dados, a DML (Data Manipulation Language) para ma-
nipulação dos dados (inclusão, alteração, exclusão) e a DDL (Data Definition Language) para
criar, alterar ou excluir estruturas (esquemas) do banco de dados.
c) Errada. O conceito a abordado não é de consistência e sim de redundância.
d) Certa. O princípio da atomicidade (tudo ou nada) é um dos princípios que devem ser se-
guidos durante uma transação, também conhecido como ACID: Atomicidade, Consistência,
Isolamento e Durabilidade.
e) Errada. Essa alternativa, eu creio, deva ter deixado você pensando bastante, vamos lá. O erro
está em chamar o “controle de concorrência” de “princípio” sendo que os princípios que servem
para garantir a eficácia de uma transação em banco de dados fazem parte do ACID: Atomici-
dade, Consistência, Isolamento e Durabilidade. O controle de concorrência é uma forma de
prevenir problemas durante uma concorrência e ela deve se pautar no ACID, mas este controle
não é um princípio em si mesmo.
Letra d.
007. (CEBRASPE/CESPE/TRF-1ªREGIÃO/ANALISTA JUDICIÁRIO/2017/Q930059) A res-

peito dos conceitos de banco de dados, normalização, controle de concorrência e modelagem,
julgue os itens subsecutivos.
Atomicidade é a propriedade que garante que as transações não sejam afetadas pelo funcio-
namento umas das outras nem tenham acesso aos resultados parciais entre si.
Antes de comentar, gostaria de aconselhar que sempre nas revisões sobre o assunto, incluam
a revisão sobre os princípios que devem ser seguidos por uma transação ou seja o ACID.
BANCO DE DADOS E BI
A questão tenta confundir você, apresentando o princípio do Isolamento, afirmando que se tra-
ta do princípio da Atomicidade. Um detalhe capcioso da questão é quando ela descreve “...nem
tenham acesso aos resultados parciais entre si.”, neste caso, isso ocorreria se não houvesse
isolamento na transação. Vamos relembrar o ACID:
• 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 comple-
to, não deixando parte das operações sendo executadas com sucesso e outras fiquem
pendentes, causando inconsistências futuras nos dados;
• 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 simul-
tâneo a um mesmo dado seja tratado como se fosse sequencial, garantindo que uma
transação não seja afetada por outra concorrente, sem que haja falha percebida pelo
usuário ou aplicação;
• Durabilidade: É propriedade que o SGBD deve ter de que uma transação já executada
(efetivada), permaneça neste estado mesmo havendo algum problema de falha no sis-
tema algum travamento em sistema operacional ou até mesmo queda de energia.
Errado.
008. (CEBRASPE/CESPE/SE-DF/PROFESSOR INFORMÁTICA/2017/Q852599) Julgue os

itens a seguir, a respeito de banco de dados, organização de arquivos, métodos de acesso e
banco de dados textuais.
Em sistemas de gerenciamento de banco de dados, por motivos de desempenho, o tratamento
de concorrência pode resultar em intercalações de ações realizadas sobre o banco de dados.
Essa questão, infelizmente, derrubou muitos(as) candidatos(a)s, mas, vamos entender os mo-
tivos. O que a banca quer na verdade saber, é se você consegue relacionar o fato de o SGBD
conseguir realizar o controle de transações e este controle também causar uma melhora do
seu desempenho. As transações, quando executadas, elas são intercaladas para evitar efeitos
de deadlocks. O deadlock ocorre quando duas ou mais tarefas bloqueiam uma à outra perma-
nentemente, sendo que cada uma tem o bloqueio de um recurso (dado ou conjunto de dados)
que a outra tarefa está tentando bloquear, e a forma de se evitar isso, é isolando cada uma das
tarefas, intercalando com uso de transações. O controle das transações, contribui para a não
ocorrência do deadlock, melhorando a performance do banco de dados.
Certo.
009. (CEBRASPE/CESPE/TC-PA/ANALISA DE SISTEMAS/2016/Q814100) Julgue os itens

subsequentes, no que se refere a sistemas de gerenciamento de bancos de dados (SGBD).
BANCO DE DADOS E BI
Independência lógica de dados refere-se à capacidade de alterar o esquema conceitual sem a

necessidade de alterar os esquemas externos ou os programas de aplicação.
É exatamente isso!
Vejamos abaixo uma figura para relembrar os conceitos sobre Independência de Dados:
Certo.
010. (CEBRASPE/CESPE/TC-PA/ANALISA DE SISTEMAS/2016/Q814099) Julgue os itens

subsequentes, no que se refere a sistemas de gerenciamento de bancos de dados (SGBD).
A principal característica da abordagem de banco de dados consiste em apresentar as ferra-
mentas de acesso físico dependentes da plataforma de armazenamento.
É justamente o contrário, não há dependência. Ao se utilizar um SGBD, um dos principais com-

ponentes é o catálogo do sistema de dados, é nele que ficam armazenados as informações
referente as estruturas (esquemas) dos bancos de dados e isso independente e isolado das
outras ferramentas, inclusive essa é uma das vantagens apontadas pelo Navathe, no caso, o
isolamento entre programas e dados, vejamos o que ele diz a respeito:
• Natureza de autodescrição de um sistema de banco de dados: Utilização do catálogo
para armazenamento das estruturas das bases de dados;
• Isolamento entre programas e dados, e abstração de dados: a estrutura dos arquivos de
dados é armazenada no catálogo do SGBD separado dos programas de acesso;
BANCO DE DADOS E BI
• Suporte para múltiplas visões de dados: Capacidade de visualizar os diversos dados em

diversas visões a depender da necessidade dos usuários, através do uso da linguagem
SQL;
• Compartilhamento de dados e processamento de transação multiusuário: Possibilita o
acesso simultâneo e concorrente por diversos usuários e aplicações, de forma contro-
lada.
Errado.
011. (CEBRASPE/CESPE/TC-PA/ADMINISTRADOR DE BANCO DE DADOS/2016/Q813832)

O SGBD deve possuir um controle de concorrência que garanta a manipulação controlada de
um mesmo dado por múltiplos usuários, a fim de assegurar que os resultados das atualiza-
ções sejam corretos.
Uma das vantagens em se utilizar um SGBD é fato dele dispor de recursos para controle de
concorrência, evitando conflitos de tarefas simultâneas requisitadas por diferentes usuários,
o que pode causar deadlock e consequentemente o travamento da aplicação. O compartilha-
mento de dados e o processamento de transação multiusuário, inclusive são vantagens apon-
tadas pelo autor querido da banca CESPE/Cebraspe, o Navathe, no uso do SGBD.
Certo.
012. (CEBRASPE/CESPE/TC-PA/ADMINISTRADOR DE BANCO DE DADOS/2016/Q813831)

Com relação a sistemas gerenciadores de bancos de dados (SGBD), julgue os próximos itens.
No nível conceitual da arquitetura de três camadas de banco de dados, cada esquema externo
descreve a parte do banco que interessa a determinado grupo de usuários e oculta desse gru-
po o restante do banco de dados.
Questões maldosas sempre surgem e essa é uma delas. Existe um “peguinha” aqui nesta ques-
tão, vou apresentar uma figura da Arquitetura em 3 esquemas, de autoria do Navathe (sim, o
autor querido da banca CESPE/Cebraspe), e nela irei explicar onde está o “peguinha”, vejamos:
BANCO DE DADOS E BI
Perceba que a figura apresenta três níveis:

• Nível Externo: Está mais próximo do usuário, onde modelo apresentado é de alto nível,
sem detalhes de como será implementado;
• Nível Conceitual: Através do mapeamento do nível externo, é possível definir o esquema
conceitual, onde nele conterão descrições sobre as entidades, tipos de dados e relacio-
namentos, estando ainda oculto detalhes da estrutura de armazenamento físico;
• Nível Físico: Descreve detalhes da estrutura física de armazenamento e os caminhos de
armazenamento e acesso aos dados.
Percebeu o trocadilho feito na questão? Não?! Vou te mostrar.
Não existe “esquema externo”, é nível externo. Os esquemas construídos são Esquema Con-
ceitual e Esquema Lógico e não é no nível conceitual que são demonstradas as partes do ban-
co de dados que interessam aos usuários, pois isso pertence ao nível externo.
Maldade pura essa questão.
Errado.
013. (CEBRASPE/CESPE/TJ-DFT/ANALISTA DE SISTEMAS/2015/Q833406) Um banco de

dados permite à aplicação o armazenamento e a recuperação de dados com eficiência, o que
garante segurança e integridade das informações. No caso de banco de dados relacional, os
BANCO DE DADOS E BI
dados são armazenados em tabelas e os relacionamentos entre elas as tornam relacionais. A

esse respeito, julgue os itens que se seguem.
Um banco de dados em grafos está diretamente relacionado a um modelo de dados já estabe-
lecido, o que viabiliza recomendar a utilização para os casos em que a interconectividade dos
dados é tão importante quanto os próprios dados.
Com o crescente volume de dados, principalmente dados semiestruturados, manter no merca-

do apenas SGBD oferecendo uma arquitetura que exige a construção de um esquema estrutu-
rado (tabelas, colunas, relacionamentos) não foi o suficiente, daí surgiram os SGBDs NoSQL,
oferecendo diversas soluções de acordo com o formato dos dados e objetivos dos negócios.
Dentre eles, existem os SGBDs NoSQL orientados a grafos, com as seguintes características:
• 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
dados 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 relacio-
namento entre dois nós. Cada nó em um banco de dados baseado em grafos é definido
por um identificador exclusivo, um conjunto de arestas de saída e/ou arestas de entrada
e um conjunto de propriedades expressas como pares de chave/valor.
Certo.
014. (CEBRASPE/CESPE/FNDE/ADMINISTRADOR DE BANCO DE DADOS/2015/Q798877)

No processo de modelagem do banco de dados, o modelo conceitual deve realizar uma descri-
ção das estruturas onde serão armazenados os dados, uma vez que, nessa fase, é fundamen-
tal ter definida a estrutura do sistema gerenciador de banco de dados.
No Nível Conceitual, que é resultado do mapeamento do Nível Externo (visão do usuário), são
definidos as estruturas e os tipos de dados, mas não onde eles serão armazenados, este deta-
lhe pertence ao Nível Físico, e não o Conceitual.
Errado.
015. (CEBRASPE/CESPE/TELEBRAS/ENGENHEIRO DA COMPUTAÇÃO/2015/Q798118)

Com relação a desenvolvimento de sistemas, julgue os itens que se seguem.
BANCO DE DADOS E BI
A arquitetura lógica de um sistema de gerenciamento de banco de dados (SGBD) lida com a

forma como os dados são armazenados e apresentados ao usuário, ao passo que a arquitetu-
ra física ocupa-se dos componentes de software que compõem um SGBD.
O projeto lógico, apesar de não revelar detalhes dos componentes de software e que fazem
parte do projeto físico, nele são descritas as estruturas dos dados, contendo as tabelas, os
tipos dos atributos e a forma de relacionamento entre as tabelas. Esta estrutura define como
são armazenados os dados, mas não onde são armazenados fisicamente, este último, fica a
cargo do projeto físico do SGBD.
Certo.
016. (CEBRASPE/CESPE/CAPES/ANALISTA DE SISTEMAS/2015/Q793366) Com relação

aos passos do processo de projeto de bancos de dados e de modelagem de dados relacional
e dimensional, julgue os itens subsequentes.
O modelo lógico é considerado um modelo de dados implementável, portanto recomenda-se
que seja criado a partir do mapeamento do modelo conceitual de dados.
Questão perfeita!
Quando se fala em modelo de dados implementável, é porque no modelo lógico são represen-
tadas as estruturas das tabelas, contendo as colunas com seus tipos definidos, bem como os
relacionamentos possíveis entre estas tabelas. Não surge do nada, existe um modelo concei-
tual que foi levantado, aprovado e que serviu de insumo para elaboração do modelo lógico.
Certo.
017. (CEBRASPE/CESPE/CAPES/ANALISTA DE SISTEMAS/2015/Q793365) Com relação

aos passos do processo de projeto de bancos de dados e de modelagem de dados relacional
e dimensional, julgue os itens subsequentes.
O modelo conceitual corresponde ao mais baixo nível de abstração, visto que estabelece como
os dados são armazenados. Trata-se de um modelo simples, de fácil compreensão pelo usuá-
rio final, além de independente de um SGBD particular.
Questão fácil e já eliminada na primeira parte da descrição.

O nível mais baixo de abstração é o nível físico e não o nível conceitual, onde lá será mostrado,
de forma efetiva, como os dados estão armazenados e qual tecnologia está sendo usada.
A segunda parte do enunciado retrata as características do nível conceitual, porém a questão
já estava errada desde o início.
Errado.
BANCO DE DADOS E BI
018. (CEBRASPE/CESPE/BANCO DA AMAZÔNIA/ADMINISTRAÇÃO DE DADOS/2010)

Com relação aos projetos de banco de dados, julgue os itens subsequentes.
Um projeto de banco de dados pressupõe etapas que incluem análise de requisitos, projeto
conceitual, projeto lógico e projeto físico.
Questão perfeita para uma revisão em véspera de provas!

Segundo o autor querido da banca CESPE/Cebraspe, Navathe:
Podemos identificar seis fases principais do processo geral de projeto e implementação do banco
de dados:
1.Levantamento e análise de requisitos.
2. Projeto conceitual do banco de dados.
3. Escolha do SGBD.
4. Mapeamento do modelo de dados (também chamado de projeto lógico do banco de dados).
5. Projeto físico do banco de dados.
6. Implementação e ajuste do sistema de banco de dados.
Certo.
019. (CEBRASPE/CESPE/FNDE/DESENVOLVEDOR/2015/Q792431) A respeito de sistemas

gerenciadores de bancos de dados (SGBD), julgue os itens a seguir.
Para implementar um SGBD, são necessários três componentes: linguagem de definição de
dados, linguagem de manipulação de dados e dicionário de dados.
Questão inteligente essa, mas perigosa por sua simplicidade.

Apesar da banca CESPE/Cebraspe adotar para este assunto, na maioria das vezes, o livro do
Navathe, neste caso ela preferiu um outro livro, o do Laudon & Laudon, chamado “Sistemas de
Informações Gerenciais”, onde os Laudons dizem o seguinte: “Sistema de gerenciamento de
banco de dados tem três componentes: uma linguagem de definição de dados, uma linguagem
de manipulação de dados e um dicionário de dados.”
Os Laudons também falam em sua obra sobre dicionário de dados, afirmando que se trata
de um arquivo automatizado que armazena informações de dados e outras características,
como padrões de utilização, propriedade, relacionamentos entre os elementos de dados e a
segurança. Ele identifica quais dados existem no banco de dados, sua estrutura e formato, e
sua utilização na empresa tanto para usuários finais como para os empresários especialistas.
Certo.
020. (CEBRASPE/CESPE/FNDE/DESENVOLVEDOR/2015/Q792430) A respeito de sistemas

gerenciadores de bancos de dados (SGBD), julgue os itens a seguir.
Os programas usados em um SGBD permitem criação de estruturas, manutenção de dados,
gerenciamento de transações efetuadas em tabelas e extração de informações.
BANCO DE DADOS E BI
Sim, é claro!
Uma das vantagens em se utilizar um SGBD, é devido a disponibilidade de recursos que inter-
pretam e compilam comandos usando linguagem capaz criar estruturas, alterar estruturas e
manipular dados, conhecidas como SQL (Structured Query Language), utilizada para obtenção
de dados, a DML (Data Manipulation Language) para manipulação dos dados (inclusão, alte-
ração, exclusão) e a DDL (Data Definition Language) para criar, alterar ou excluir estruturas
(esquemas) do banco de dados.
Além disso, existem recursos para controle de concorrência, utilizando o gerenciamento de
transações, garantindo assim a consistência e integridade dos dados.
Certo.
021. (CEBRASPE/CESPE/MEC/ARQUITETO DE SISTEMAS/2011/Q741337) Acerca de ban-

co de dados, OLAP, normalização e MVC, julgue os itens subsequentes.
Para garantir que haja visão abstrata do banco de dados, o SGBD possui três níveis de abs-
tração. No nível de abstração de usuário, são definidos quais os dados estão armazenados e
quais são os seus relacionamentos.
Olha, a banca CESPE/Cebraspe gosta de jogar com as palavras para tentar iludir o candidato(a)
e nesta questão não foi diferente. Vejamos.
Existem 3 níveis na Arquitetura de 3 esquemas, sendo o mais abstrato aquela em que o usuário
tem acesso a partes do banco de dados, seja por uma necessidade individual ou de um grupo
de usuários da organização. Neste nível não se conhece sobre as estruturas dos dados e seus
relacionamentos, nem tão pouco quais dados estão armazenados. Tudo isso fica com o Nível
Conceitual e esse é o erro da questão.
Errado.
022. (CEBRASPE/CESPE/TJSE/SUPORTE TECNICO EM INFRAESTRUTURA/2014/

Q442355) Julgue os itens a seguir, relativos à administração de banco de dados e ao sistema
de gerenciamento de banco de dados (SGBD).
Um SGBD deve gerenciar o acesso múltiplo aos dados de uma tabela sem ocasionar perda da
integridade dessas informações.
Perfeita a questão, que trata sobre o gerenciamento de transações, controlando a concorrên-

cia no uso de um mesmo recurso de dados no SGBD. Vale lembrar que no gerenciamento de
transações, deve-se levar em consideração os princípios do ACID: Atomicidade, Consistência,
Isolamento e Durabilidade.
Certo.
BANCO DE DADOS E BI
023. (CEBRASPE/CESPE/TJ-SE/SUPORTE TECNICO EM INFRAESTRUTURA/2014/

Q741335) Julgue os itens a seguir, relativos à administração de banco de dados e ao sistema
de gerenciamento de banco de dados (SGBD).
Os dados físicos de um banco de dados podem ser acessados diretamente por meio de qual-
quer sistema, sem a necessidade de utilização do SGBD.
A tentativa de acesso será frustrada, uma vez que se faz necessário utilizar alguns recursos
internos do SGBD, como por exemplo o catálogo do sistema para poder ter acesso a estrutura
dos esquemas armazenados e que a depender do SGBD (Oracle, MySQL, PostgreSQL, SQL Ser-
ver, ou outro) utilizado, existirão detalhes de implementação de cada um que podem dificultar
o acesso direto, como por exemplo, a compressão dos arquivos de dados.
Errado.
024. (CEBRASPE/CESPE/MEC/ARQUITETO DE SISTEMAS/2011) Acerca de banco de da-

dos, OLAP, normalização e MVC, julgue os itens subsequentes.
Em um projeto de banco de dados, o modelo conceitual e o modelo lógico definem as enti-
dades e seus relacionamentos. O primeiro modelo independe do tipo de SGBD e o segundo
depende do tipo de SGBD a ser utilizado.
Questão de revisão, ela retrata muito bem o que já foi visto anteriormente sobre as caracterís-
ticas dos modelos conceitual, lógico e físico e nós vimos que o modelo conceitual está mais
perto do usuário final, do cliente, onde a visão deve ser o mais simples possível e independen-
te da tecnologia que será utilizada. O modelo lógico já possui uma representação não muito
superficial e nem muito técnica do ponto de vista físico do banco de dados, porém mantém um
alinhamento com a tecnologia que será utilizada na solução, no caso, o Sistema Gerenciador
de Banco de Dados – SGBD. O modelo físico, este sim, está bem atrelado ao SGBD que será
utilizado e suas particularidades de arquitetura, infraestrutura, organização dos arquivos e
índices, dentre outras.
O tipo de SGBD que o modelo lógico trata é se ele é relacional, orientado a objetos, hierárquico,
em rede, dentro outros. Não é o software que será usado para construir o modelo lógico, este
é apenas uma ferramenta. A banca adora trazer este tipo de “pegadinha”, cuidado.
Certo.
025. (CEBRASPE/CESPE/TC-DF/ANALISTA DE ADMINISTRAÇÃO/2014/Q726491) Com re-

lação a projetos de bancos de dados, modelo entidade relacionamento e linguagens utilizadas
em bancos de dados, julgue os próximos itens.
BANCO DE DADOS E BI
Durante a implementação de um banco de dados, a especificação dos esquemas conceitual

e interno é realizado por meio do uso de uma linguagem de definição de dados, mesmo nos
SGBD em que haja uma separação clara entre os níveis conceitual e interno.
A questão aborda duas linguagens utilizadas em SGBD para trabalhar com a definição da es-
trutura do banco de dados, porem uma em nível conceitual (DDL– Data Definition Language)
e a outra em nível físico (SDL – Storage Definition Language). A maioria dos SGBD não dispo-
nibiliza o uso separado das linguagens, procurando deixar a mais fácil para ser utilizada pelo
usuário, que seria, a DDL, porém quando o SGBD disponibiliza claramente a possibilidade de
trabalhar de forma independente cada nível, então é possível usar a SDL.
O erro da questão está em afirmar que quando o SGBD tem a claramente a separação dos
níveis conceitual e interno, mesmo assim, é usada a DDL, o que não é verdade, pois existe a
possibilidade de utilizar a SDL.
Errado.
026. (CEBRASPE/CESPE/MEC/ADMINISTRADOR DE BANCO DE DADOS/2011) Julgue os

itens a seguir, relativos à transformação do modelo conceitual.
Quando se transforma um modelo conceitual em um modelo lógico, os dados passam a ser
vistos como estruturas de dados voltadas para as características do modelo lógico escolhido
(hierárquico, rede, relacional etc.).
Nós já vimos em comentários anteriores que o modelo conceitual está em mais alto nível, inde-
pendente da tecnologia que será usada, mais próximo do cliente, das descrições dos requisitos
e suas restrições. Vimos também que o modelo lógico tem como característica principal o fato
de estar mais alinhado com a tecnologia que será usada pelo SGBD. Como já sabemos que no
modelo lógico já podemos ter a visão da tecnologia que será aplicada, concluímos que a mo-
delagem neste momento seguirá as características do modelo lógico escolhido.
Certo.
027. (CEBRASPE/CESPE/CEF/TÉCNICO BANCÁRIO/2014/Q713568) Acerca dos conceitos

de SGBDs, julgue os itens a seguir.
Um SGBD deve possibilitar a independência lógica de dados, que é a capacidade de alterar a
estrutura de armazenamento das informações, como, por exemplo, acrescentar disco e au-
mentar o tamanho das consultas, sem necessidade de modificar as características do sistema
operacional que hospeda o SGBD.
A questão faz um trocadilho entre o conceito de Independência Lógica de Dados e Indepen-

dência Física de Dados. Para ajudar a entender melhor, trago abaixo a citação do Navathe
sobre o assunto, vejamos:
BANCO DE DADOS E BI
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.
No caso da questão, o trecho “...alterar a estrutura de armazenamento das informações, como,
por exemplo, acrescentar disco e aumentar o tamanho das consultas.” trata-se de Independên-
cia Física de Dados.
Errado.
028. (CEBRASPE/CESPE/TRT-17ª/ANALISTA JUDICIÁRIO/TI/2013/Q722677) No que se

refere aos sistemas de gerenciadores de banco de dados (SGBD), julgue os itens seguintes.
Assim como no modelo conceitual, o modelo lógico de dados não possui atributos, uma vez
que, no primeiro caso, o objetivo é descrever as informações sob o contexto do negócio, ao
passo que no segundo caso o objetivo envolve a lógica dos relacionamentos dos dados sem a
preocupação de conhecer as estruturas físicas e o SGBD específico que será utilizado.
Questão bem apelativa no sentido da tentativa de convencer que está correto. Vejamos.
No modelo lógico de dados não possui atributos?! Quem disse isso?!
No modelo lógico é definida a estrutura das tabelas e quais atributos e relacionamentos ela terá.
Questão absurdamente errada.
Errado.
029. (CEBRASPE/CESPE/DPF/PERITO CRIMINAL/2013/Q674559) No que se refere a arqui-

tetura, modelos lógicos e representação física de banco de dados e implementação de SGBDs
relacionais, julgue os itens que se seguem.
A arquitetura ANSI de três níveis separa o nível externo dos usuários, o nível conceitual do
banco de dados e o nível de armazenamento interno no projeto de um banco de dados. O nível
interno tem um esquema interno, que descreve a estrutura do armazenamento físico do banco
de dados e descreve os detalhes completos do armazenamento de dados e os caminhos de
acesso para o banco de dados.
Questão perfeita e recomendo separá-la para revisão de véspera de prova, segue abaixo figura
que complementa o enunciado assertivo da questão.
BANCO DE DADOS E BI
Certo.
030. (CEBRASPE/CESPE/TC-RO/ANALISTA DE INFORMÁTICA/2013/Q667980) Em rela-

ção à implementação de banco de dados, julgue os itens subsecutivos.
Um SGBD garante que haja repetição de informação para que seja possível aplicar as regras
de normalização.
A teoria sobre normalização veremos nas próximas aulas, quando formos tratar de modela-
gem de dados, mas posso adiantar que a normalização de dados é utilizada para resolver pro-
blemas de redundância de dados nas entidades, através do uso das formas normais e chaves
primárias e estrangeiras.
A questão apela ao dizer que o SGBD proporciona a repetição, sendo que não é verdade, uma
vez que o SGBD surgiu justamente para mitigar este tipo de problema, mas, como as estrutu-
ras dos dados são criados por pessoas, então pode haver inicialmente má definição de cam-
pos e tabelas e ser necessário aplicar as técnicas de normalização para então corrigir estas
anomalias.
Errado.
BANCO DE DADOS E BI
031. (CEBRASPE/CESPE/TC-RO/ANALISTA DE INFORMÁTICA/2013/Q667979) Em rela-

ção à implementação de banco de dados, julgue os itens subsecutivos.
O projeto físico é direcionado para um SGBD específico como, por exemplo, Oracle, Postgresql
ou SQLServer. Decisões tomadas durante o projeto físico para melhorar o desempenho podem
afetar a estrutura do esquema lógico.
Sim, o projeto físico atende a um SGBD específico e que foi decidido pelo projetista e demais
membros da equipe do projeto, ou por necessidade da organização ou do negócio em si. Al-
terações na estrutura física do projeto do banco de dados é muito comum, por exemplo, para
melhorar a performance ou até mesmo novos critérios de segurança de acesso e auditoria de
dados (histórico de operações realizadas no banco de dados por usuários e/o aplicações ex-
ternas). Estas alterações podem, de fato, afetar o esquema lógico definido anteriormente, ou
seja, novas tabelas podem surgir, novos atributos podem ser criados, por exemplo.
Certo.
032. (CEBRASPE/CESPE/TRE-RJ/PROGRAMAÇÃO DE SISTEMAS/2012) Julgue os seguin-

tes itens, relativos à modelagem de dados: diagramas entidade-relacionamento e mapeamen-
to para modelo relacional.
No modelo relacional, os dados são representados por um conjunto de registros e as relações
entre esses registros são representadas por ligações, as quais podem ser vistas pelos pontei-
ros sucessivos. Os registros são organizados no banco de dados por um conjunto arbitrário
de gráficos.
A descrição apresentada na questão não está relacionada com o modelo relacional e sim com
o modelo hierárquico.
Errado.
033. (CEBRASPE/CESPE/ANTT/DESENVOLVIMENTO DE SISTEMAS DE INFORMA-

ÇÃO/2013/Q657806) Julgue os itens subsequentes, relativos a banco de dados.
Os sistemas gerenciadores de banco de dados (SGBDs) evoluíram de sistemas de arquivos
para novas estruturas de dados. O modelo em rede surgiu como extensão ao modelo hierárqui-
co (estrutura de árvore), ambos orientados a registros; o modelo relacional não tem caminhos
predefinidos para fazer acesso aos dados, mas implementa estruturas de dados organizadas
em relações (tabelas); e o modelo orientado a objetos surgiu da necessidade de representar
tipos complexos de dados utilizando semântica, em que o diagrama de classes UML serve
como esquema para representação de dados orientado a objetos.
BANCO DE DADOS E BI
Esta é uma daquelas questões que devem ser guardadas para revisão próximo do dia da prova.
Ela retrata bem a evolução dos SGBDs na linha do tempo, mesmo que não esteja abarcando
todos. Você candidato(a), poderia ter alguma dúvida mais ao final, quando a questão fala do
banco de dados orientado a objetos, porém é verdade, eles armazenam não somente atributos,
mas métodos também e surgiram pela necessidade do mercado em ter que trabalhar com da-
dos complexos, sem a rigidez da estrutura do modelo tradicional do SGBD relacional.
No SGBD Orientado a Objetos, declarações de tipo de dados são tão flexíveis quanto em lingua-
gens de programação, bem como os objetos podem ser unicamente identificados, independen-
temente dos valores de seus atributos. A utilização dos diagramas da UML para representação
é comum nestes casos, uma vez que é possível representar o modelo em um diagrama seme-
lhante ao diagrama de classes.
Certo.
034. (CEBRASPE/CESPE/CPRM/ANALISTA EM GEOCIÊNCIAS/ SISTEMAS/2013/

Q656135) No que se refere aos conceitos de administração e sistema de gerenciamento de
banco de dados (SGBD), julgue os itens que se subsecutivos.
Um SGBD utiliza o conceito de atomicidade do registro, garantindo que, detectada uma falha
na operação com o registro, os dados sejam salvos em seu último estado consistente, ante-
rior à falha.
Essa questão envolve os princípios do ACID: Atomicidade, Consistência, Isolamento e Dura-

bilidade. Neste caso, o foco está na Atomicidade, porém o contexto é do uso do ACID é na
garantia da melhor aplicabilidade da transação em casos de controle de concorrência sobre
dados no SGBD.
A Atomicidade é a propriedade que garante que a transação seja tratada de forma única, a qual
deve ser executada por completo ou não. Resumindo, é a regra do “tudo ou nada”, se a transa-
ção falhar no meio, tudo deve voltar ao estado original, assim se espera.
O erro da questão está em tratar atomicidade como sendo “atomicidade do registro” e no en-
tanto a atomicidade é da transação, que pode envolver um ou mais registros.
Errado.
035. (CEBRASPE/CESPE/SLU/DF/ANALISTA DE GESTÃO DE RESÍDUOS SÓLIDOS/2019)

No que se refere a banco de dados relacional (SQL) e não relacional (NoSQL) e ao framework
JPA, julgue o item subsecutivo.
Para uma empresa que necessite implantar uma base de dados altamente escalável, com
grande desempenho e cujo esquema de dados seja flexível, de modo que suporte constantes
mudanças de campos e valores armazenados, a melhor opção é uma base de dados NoSQL.
BANCO DE DADOS E BI
Dentre a evolução dos SGBDs na linha do tempo, atualmente o que temos de mais novo são
as bases de dados que não obrigatoriamente utilizam uma descrição previamente conhecida,
através de estruturas descritas e armazenadas em catálogo do SGBD. Muito pelo contrário,
as bases de dados NoSQL (Not only SQL), são flexíveis justamente devido ao crescimento no
mundo todo do uso e produção de dados, principalmente através das redes sociais e pelas
diversas aplicações existentes. Atualmente podemos classificar os bancos de dados NoSQL
da seguinte forma:
• Modelo orientado a chave-valor;
• Modelo orientado a documentos;
• Modelo orientado a colunas;
• Modelo orientado a grafos.
Certo.
036. (CEBRASPE/CESPE/PF/PAPILOSCOPISTA/2018) Julgue o item seguinte, a respeito de

big data e tecnologias relacionadas a esse conceito.
De maneira geral, big data não se refere apenas aos dados, mas também às soluções tecnoló-
gicas criadas para lidar com dados em volume, variedade e velocidade significativos.
Isso mesmo, e estas soluções envolvem tecnologias que são capazes de trabalhar com o con-
trole de entrada dos dados via streaming, por exemplo através do framework Apache Kafka,
além de soluções para processamento de dados em grandes volumes, como o Hadoop através
do seu sistema de arquivos HDFS e no tocante a variedade, temos os bancos de dados NoSQL
como alternativa de armazenamento.
Certo.
037. (CEBRASPE/CESPE/TCM-BA/AUDITOR ESTADUAL DE CONTROLE EXTERNO/2018) O

diretor de uma montadora de veículos necessita tomar uma decisão acerca da continuidade ou
não de um dos produtos vendidos no Brasil. Para tanto, solicitou um relatório sobre as vendas
de carros da marca do último trimestre de 2018, por faixa de preço, região, modelo e cor. Nessa
situação, no contexto de análise da informação, o relatório representa
a) conhecimento.
b) inteligência.
c) dados.
d) informação.
e) sabedoria.
BANCO DE DADOS E BI
Essa questão aborda um assunto interessante, que é a diferenciação entre: Dados, Informação,
Conhecimento e Inteligência. Trazendo para o nosso objetivo, que é estudar sobre Banco de
dados, faz todo sentido pois tudo evolui a partir da menor unidade que é o dado em si.
O “relatório de vendas” apresentado na questão é a materialização da utilização dos dados
para fins de prover informação para um ou mais usuários. A partir desta informação é possível
produzir conhecimento.
Alguns autores tratam a “inteligência” e a “sabedoria” como sendo a mesma coisa, porém, se
faz mais presente da literatura o uso do termo “inteligência”. Trago abaixo uma breve descrição
sobre cada um:
• Dados: Podem ser definidos como resultados de eventos do mundo real, onde seu con-
teú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;
• Informações: São definidas em algum contexto e que por sua vez para que produzam
informação fazem uso dos dados, que foram processados;
• Conhecimento: Com base no uso das informações é possível colocá-las em ação e as-
sim gerar conhecimento. Podemos dizer que o conhecimento tem relação com a capa-
cidade de alguém interpretar e sintetizar um conjunto de informações e associá-las com
outros conjuntos de informações, com base nas experiências, feeling, impressões ou
até crenças e daí tirar conclusões sobre algum assunto ou problema;
• Inteligência (sabedoria): Quando o conhecimento é encarado como sendo oportunida-
de, podemos dizer que estamos diante da inteligência, ou seja, a aplicação do conheci-
mento em um ambiente considerado propício, pode gerar vantagem competitiva para
uma organização, por exemplo.
Letra d.
038. (CEBRASPE/CESPE/TRT-17ª/ES/TÉCNICO JUDICIÁRIO/TI/2013) Com relação aos

conceitos de modelo de entidade e relacionamento e de modelo conceitual, lógico e físico,
julgue os itens subsecutivos.
O esquema conceitual caracteriza-se por ser um conjunto de entidades que permitem a visuali-
zação do conteúdo das tabelas existentes no banco de dados. Sua definição é armazenada no
dicionário de dados e somente é calculada quando seu conteúdo for executado.
O esquema conceitual, resultante da modelagem conceitual, está mais próximo do usuário

final do banco de dados. Neste cenário, não há da parte deste usuário conhecimento sobre o
BANCO DE DADOS E BI
conteúdo das tabelas. Este conhecimento se dá a partir da fase próxima fase de mapeamento
dos dados, onde a estrutura começará a ser definida a partir do projeto lógico, caminhando
para o projeto físico.
Errado.
039. (CEBRASPE/CESPE/TRE-MS/PROGRAMADOR/2013) A estrutura que, além de ser or-

ganizada sob a forma de uma lista organizada de todos os elementos de dados pertinentes
ao sistema, também constitui um ponto de referência de todos os elementos desse sistema,
permitindo associar um significado a cada termo utilizado, é tecnicamente conhecida como:
a) visão (view).
b) stored procedure (procedimento armazenado).
c) trigger (gatilho).
d) dicionário de dados.
e) esquema de banco de dados.
Vamos por partes!

a) Errada. A visão (view) no contexto de obtenção de dados no SGBD, trata do uso de lingua-
gem SQL para elaboração de diferentes visões sobre os dados a partir dos dados armazena-
dos em uma ou mais tabelas. Geralmente usado para não ter que executar um comando SQL
para obter os mesmos dados todas as vezes.
b) Errada. As store procedures são códigos armazenados em SGBDs específicos, sendo utili-
zado para fins diversos, sendo um deles, por estratégia do DBA ou do desenvolvedor da apli-
cação, por achar que a performance possa ser melhor, reduzindo o tráfego na rede, pois o co-
mando será executado no próprio SGBD sem necessidade de ser executada via uma aplicação
externa.
c) Errada. Os gatilhos são formados por comandos em SQL, que também ficam armazenados
no SGBD, porém a sua execução é predeterminada, ou seja, é possível informar em que mo-
mento ele será executado, geralmente antes ou depois de uma atualização de dados. É muito
usado para fins de preencher tabelas automaticamente com dados históricos, que foram alte-
rados ou excluídos no decorrer do tempo, garantindo uma auditoria futura na base de dados.
d) Certa. É o gabarito da questão, porém atenção para não confundir dicionário de dados com
o catálogo do sistema de banco de dados, pois o primeiro é mais abrangente e geralmente fica
fora do SGBD.
e) Errada. O esquema do banco de dados fica armazenado no catálogo do sistema de banco
de dados e descreve a estrutura do banco criado.
Letra d.
040. (CEBRASPE/CESPE/BANCO DA AMAZÔNIA/TÉCNICO CIENTÍFICO/BANCO DE DA-

DOS/2012) O dicionário de dados é um repositório utilizado com a finalidade de armazenar
informações dos atributos de cada entidade com o maior número de detalhe possível.
BANCO DE DADOS E BI
O dicionário de dados, como a questão fala, é um repositório, mantido fora do SGBD. Geralmen-
te existem ferramentas próprias para administração destes dados e que vão além do que exis-
te no catálogo do SGBD, importante não confundir um com o outro. Veja um exemplo abaixo
de dicionário de dados:
Certo.
041. (CEBRASPE/CESPE/HEMOBRÁS/ADMINISTRADOR DE BANCO DE DADOS/2008) As

modificações no esquema do banco de dados ou no modelo físico são implementadas com
um conjunto de sentenças DML (data manipulation language) para gerar modificações nas
respectivas tabelas internas do sistema, como por exemplo, o dicionário de dados.
As modificações em nível de estrutura são feitas pelas sentenças na linguagem DDL (DDL–
Data Definition Language) e não DML. As sentenças em DML operam com os dados armaze-
nados, incluindo, alterando ou excluindo, por exemplo.
Errado.
042. (CEBRASPE/CESPE/PF/PERITO CRIMINAL/ÁREA 3/2018) Acerca de banco de dados,

julgue o item seguinte.
NoSQL são bancos de dados que não aceitam expressões SQL e devem ser armazena-
dos na nuvem.
É o tipo de questão que tenta pegar o(a) candidato(a) que não estudou, induzindo ao erro de
interpretação na sigla NoSQL, como se ela significasse “sem SQL” ou “não SQL” e no entanto
significa “No only SQL”, permitindo armazenar dados estruturados e semiestruturados. Apesar
do uso da nuvem ser uma vantagem devido ao volume de dados que geralmente são proces-
sados, nada impede de se ter um banco de dados NoSQL instalado e funcionando em um
servidor local.
Errado.
BANCO DE DADOS E BI
043. (CEBRASPE/CESPE/EBSERH/ANALISTA DE TI/2018) Com relação a banco de dados,

julgue o item seguinte.
As soluções de big data focalizam dados que já existem, descartam dados não estruturados e
disponibilizam os dados estruturados.
As soluções em big data surgem em um contexto em que a quantidade e variedade de dados

aumentam, em velocidade quase exponencial, no mundo todo. Esta variedade faz com que
as soluções em big data sejam flexíveis e não focadas em dados estruturados, muito pelo
contrário, neste universo crescente de dados, a quantidade de dados não estruturados tem se
sobressaído cada vez mais. Para isso existem os bancos de dados NoSQL, capazes de arma-
zenar dados estruturados e não estruturados.
Fácil, não acha?!
Errado.
044. (CEBRASPE/CESPE/FUNPRESP-JUD/ANALISTA DE TI/2016) Julgue o item subsecuti-

vo, referente às tecnologias de bancos de dados.
Em um banco de dados NoSQL orientado a documentos, a inexistência de um esquema impos-
sibilita a definição de índices.
Vejamos as características de um banco NoSQL 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.
Errado.
045. (CEBRASPE/CESPE/BANCO DA AMAZÔNIA/ADMINISTRAÇÃO DE DADOS/2010)

Acerca da divisão nos níveis interno, conceitual e externo relativos à arquitetura de banco de
dados (BD), julgue os itens a seguir.
Se um sistema de banco de dados provê independência física dos dados, é correto inferir que
esse sistema também permite independência lógica de dados.
Já conhecido durante nosso o estudo na aula, a partir da Arquitetura em 3 Esquemas, que exis-
te o pressuposto da Independência de Dados apontada pelo Navathe em sua obra, mas, existe
uma ressalva, ele mesmo nos mostra, vejamos:
BANCO DE DADOS E BI
... 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.)
Resumindo, não podemos garantir que havendo independência física de dados teríamos tam-
bém a independência lógica de dados.
Errado.
046. (CEBRASPE/CESPE/TJ-DFT/SUPORTE EM TI/2015) A respeito de tipos de bancos de

dados, julgue o item que se segue.
Sistemas de bancos de dados classificados como NoSQL permitem a inserção de dados sem
que haja um esquema predefinido.
Perfeito, esse conceito foi abordado em diversas questões acima. A premissa básica dos ban-
cos NoSQL é que não haja um esquema predefinido, o que permite trabalhar com dados estru-
turados e semiestruturados.
Certo.
047. (CEBRASPE/CESPE/MEC/ADMINISTRADOR DE BANCO DE DADOS/2015) Julgue o

item seguinte a respeito do projeto lógico e físico de banco de dados.
No projeto lógico, o modelo físico é obtido por meio da transformação do modelo conceitual.
A sequência de elaboração dos modelos, parte do modelo conceitual (alto nível, visão mais
próxima do usuário), passando pelo modelo lógico (onde as tabelas, colunas e relacionamen-
tos são definidos) e chegando ao modelo físico.
Errado.
048. (CEBRASPE/CESPE/TCU/AFC-TI/2015) Julgue o item subsecutivo, a respeito de siste-

mas de bancos de dados.
Como forma de permitir as buscas em documentos semiestruturados, um banco de dados
NoSQL do tipo orientado a documentos armazena objetos indexados por chaves utilizando
tabelas de hash distribuídas.
De fato, os documentos em um banco de dados NoSQL são semiestruturados e podem ser

indexados por chave-valor, onde o valor é o próprio documento, ou seja, não há uso de tabelas
hash distribuídas.
Errado.
BANCO DE DADOS E BI
049. (CEBRASPE/CESPE/IPEA/ANALISTA DE SISTEMAS/2008) Com relação ao projeto, ao

monitoramento e à análise de impacto, julgue os seguintes itens.
O projeto físico de bancos de dados é tarefa essencial que ocorre iterativamente em conjunto
com análise de requisitos, projeto conceitual, refinamento do esquema e ajuste.
Sim, o projeto físico anda de acordo com a necessidade dos requisitos, pois deve refletir esta
realidade em sua implementação. O termo iterativo vem do fato que isso pode ocorrer várias
vezes a depender do grau de maturidade que os requisitos vão atingindo, podendo em cada
iteração surgir mudanças em nível conceitual, o que poderá ocasionar mudanças no projeto
físico do banco de dados.
Certo.
050. (CEBRASPE/CESPE/PEFOCE/ANALISTA DE SISTEMAS/2012) Com relação a siste-

mas de banco de dados, julgue os itens que se seguem.
O projeto conceitual de um banco de dados corresponde à descrição concisa dos requisitos de
dados, tipos de entidades, relacionamentos e restrições.
Perfeito, vimos este conceito em várias questões anteriores e perceba que é muito cobrada
pela banca CESPE/Cebraspe. Um detalhe, que talvez lhe cause dúvidas é sobre “restrições”.
As restrições são as definições dos limites de cada campo, por exemplo, eu posso definir que
um campo seja do tipo texto, de tamanho 50, e que não se admita ser vazio, esta última é uma
regra de restrição.
Certo.
BANCO DE DADOS E BI
GABARITO
1. C 18. C 35. C
2. C 19. C 36. C
3. E 20. C 37. d
4. E 21. E 38. E
5. E 22. C 39. d
6. d 23. E 40. C
7. E 24. C 41. E
8. C 25. E 42. E
9. C 26. C 43. E
10. E 27. E 44. E
11. C 28. E 45. E
12. E 29. C 46. C
13. C 30. E 47. E
14. E 31. C 48. E
15. C 32. E 49. C
16. C 33. C 50. C
17. E 34. E
Luis Octavio Lima

Analista em Tecnologia da Informação do Ministério do Planejamento, Orçamento e Gestão (MPOG)
– atual Ministério da Economia –, atualmente ocupando cargo de chefia da Divisão de Arquitetura e
Modelagem de Dados no Ministério da Justiça e Segurança Pública. Tecnólogo em Gestão da Tecnologia
da Informação pela Universidade do Sul de Santa Catarina (UniSul), especialista em Políticas Públicas e
Gestão Governtamental pela UPIS/Brasília. Possui certificações Sun Certified Java Programmer (SCJP) e
Scrum Foundation Professional Certificate (SFPC). É autor de artigos no site www.luisoctaviolima.com.br e
www.rogeraoaraujo.com.br e professor da área de Banco de Dados e Business Intelligence para concursos
públicos. Aprovado nos seguintes concursos públicos, todos na área Tecnologia da Informação: TST 2008
(classificado), TJ-DFT 2008 (classificado), STF 2008 (classificado), DER/DF 2009 (classificado), Caesb
2009 (classificado), Funasa 2009 (nomeado), MPOG (Ministério da Economia) 2009 (nomeado).

Fundamentos e Conceitos Sobre Banco de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Fundamentos e Conceitos Sobre Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

BANCO DE DADOS

Metodologia das Aulas

Cronograma das Aulas

Aula Título da Aula Conteúdo do Edital

Fundamentos e conceitos sobre

Banco de Dados: Modelo Entidade-

03 Teoria de SGDBs – Parte 2 Banco de Dados: Modelo Relacional

04 Teoria de SGDBs – Parte 3 Banco de Dados: Linguagem SQL

05 Business Intelligence I – Parte 1 Conceitos de Data Warehouse

06 Business Intelligence I – Parte 2 Conceitos de Datamining

Administração de Banco de Dados

FUNDAMENTOS E CONCEITOS SOBRE

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

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

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

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

Alguns autores tendem a trabalhar o conceito sobre dado, informação, conhecimento e

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

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

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

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

Figura 3: Elmasri & Navathe – Sistema de Banco de Dados

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

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

Figura 4: Elmasri & Navathe – Tabelas do BD Universidade

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

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

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

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

Cada estrutura criada e armazenada no catálogo apresenta sua abstração relacionada

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

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

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

Figura 5: 4 principais características do SGBD

passagens aéreas, em caso de transações simultâneas de tentativa de reserva sobre um mes-

Figura 6: Propriedades do ACID

4. Evolução e Tipos de SGBDs

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

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

Figura 8: C.J. Date – Modelo em Rede

4.2. Modelo Relacional: Década de 70

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

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

4.4. Big Data e Modelos NoSQL: Anos 2000

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

4.4.1. Modelo Orientado a Chave-Valor

Estrutura mais simples dos bancos NoSQL.

Figura 9: NoSQL – Modelo Chave-valor

Exemplos de bancos de dados orientados a chave-valor:

4.4.2. Modelo Orientado a Documentos

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

Exemplos de bancos de dados orientados a documentos:

4.4.3. Modelo Orientado a Colunas

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

Figura 10: NoSQL – Modelo Orientado a Colunas

Exemplos de bancos de dados orientados a colunas:

4.4.4. Modelo Orientado a Grafos

Figura 11: NoSQL – Modelo Orientado a Grafos

Exemplos de bancos de dados orientados a grafos:

5. Esquemas e Instâncias do Banco de Dados

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

Figura 13: Modelo em 3 níveis