ADMINISTRAÇÃO DE BANCOS DE DADOS

Prévia do material em texto

W
BA
08
80
_V
1.
0
ADMINISTRAÇÃO DE 
BANCOS DE DADOS
2
Ariel da Silva Dias 
São Paulo 
Platos Soluções Educacionais S.A 
2021
ADMINISTRAÇÃO DE BANCOS DE DADOS
1ª edição
3
2021
Platos Soluções Educacionais S.A
Alameda Santos, n° 960 – Cerqueira César
CEP: 01418-002— São Paulo — SP
Homepage: https://www.platosedu.com.br/
Diretor Presidente Platos Soluções Educacionais S.A 
Paulo de Tarso Pires de Moraes
Conselho Acadêmico
Carlos Roberto Pagani Junior
Camila Turchetti Bacan Gabiatti
Camila Braga de Oliveira Higa
Giani Vendramel de Oliveira
Gislaine Denisale Ferreira
Henrique Salustiano Silva
Mariana Gerardi Mello
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Tayra Carolina Nascimento Aleixo
Coordenador
Henrique Salustiano Silva
Revisor
Washington Henrique Carvalho Almeida
Editorial
Alessandra Cristina Fahl
Beatriz Meloni Montefusco
Carolina Yaly
Mariana de Campos Barroso
Paola Andressa Machado Leal 
Dados Internacionais de Catalogação na Publicação (CIP)_____________________________________________________________________________________ 
Dias, Ariel da Silva
D541a Administração de bancos de dados / Ariel da Silva Dias, – 
 São Paulo: Platos Soluções Educacionais S.A., 2021.
 44 p.
 
 ISBN 978-65-89965-68-8
 
 1. Banco de dados. 2. SQL Server. 3. Oracle. I. Título. 
CDD 005
____________________________________________________________________________________________
Evelyn Moraes – CRB 010289/O
© 2021 por Platos Soluções Educacionais S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser 
reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, 
eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de 
sistema de armazenamento e transmissão de informação, sem prévia autorização, 
por escrito, da Platos Soluções Educacionais S.A.
4
SUMÁRIO
Sistemas de Gerenciamento de Banco de Dados _____________ 05
Transações ___________________________________________________ 20
Backup e recuperação de banco de dados ___________________ 35
Segurança de banco de dados _______________________________ 48
ADMINISTRAÇÃO DE BANCOS DE DADOS
5
Sistemas de Gerenciamento de 
Banco de Dados
Autoria: Ariel da Silva Dias
Leitura crítica: Washington Henrique Carvalho Almeida
Objetivos
• Compreender o conceito de dados e a necessidade 
de seu gerenciamento.
• Examinar as funcionalidades de um sistema de 
gerenciamento de banco de dados.
• Relacionar um banco de dados SQL e um banco de 
dados NoSQL.
6
1. Sistemas de Gerenciamento de Banco de 
Dados (SGBD)
Então, você está construindo um aplicativo de software e um dos 
primeiros problemas a serem resolvidos é como armazenar seus 
dados. Qual banco de dados você escolherá?
Um Sistema de Gerenciamento de Banco de Dados, ou SGBD, é um 
software que se comunica com o próprio banco de dados, aplicativos 
e interfaces de usuário para obter dados e analisá-los. O SGBD 
também contém os principais instrumentos para controlar o banco de 
dados (ELMASRI, 2009; ORACLEc, 2021).
Antes de entrarmos a fundo no estudo sobre SGBD e conhecer os 
principais sistemas, analisaremos as definições de dados, banco de 
dados e gerenciadores de banco de dados.
1.1 Dados
Os dados são fatos e estatísticas armazenados ou fluindo livremente 
em uma rede ou sistema computacional, geralmente, são brutos e 
não processados. Por exemplo, quando você visita um site qualquer, 
este site pode armazenar seu endereço IP, ou seja, dados, em troca 
podem adicionar um cookie em seu navegador, indicando que você 
visitou o site, ou seja, dados. Além disso, o site pode coletar seu 
nome, idade, localização, preferências, ou seja, seus dados.
Os dados tornam-se informações quando são processados, 
transformando-os em algo significativo. Por exemplo, com base nos 
dados de cookies salvos no navegador do usuário, um site pode 
analisar os dados e obter a informação de que a maior parte das 
pessoas que visitam o site são mulheres solteiras de 26 a 40 anos, ou 
seja, informações derivadas dos dados coletados.
7
Observe que, para uma empresa (não limitando somente a 
empresas), os dados são verdadeiros tesouros preciosos. Por meio 
de uma análise profunda, é possível tirar diversas conclusões sobre 
os dados. Como no exemplo acima, onde a empresa, conhecendo seu 
público principal, pode redirecionar propagandas ou produtos que 
atendam ao interesse de mulheres solteiras, de 26 a 40 anos. Logo, os 
dados são verdadeiros tesouros que, se bem utilizados, podem gerar 
grandes oportunidades estratégicas.
1.2 Banco de dados
Um banco de dados é uma coleção de dados relacionados, 
organizados de forma que os dados possam ser facilmente 
acessados, gerenciados e atualizados. O banco de dados pode ser 
baseado em software ou hardware, com um único propósito, o 
armazenamento de dados, segundo Elmasri, (2009).
Durante os primeiros dias do computador, os dados eram coletados 
e armazenados em fitas, que eram, em sua maioria, somente 
para gravação, o que significa que, uma vez que os dados são 
armazenados, nunca mais poderão ser lidos. Eram lentos e pesados, 
e logo os cientistas da computação perceberam que precisavam de 
uma solução melhor para esse problema.
Em um banco de dados, os dados são organizados de forma que 
seja possível encontrar e gerenciar rapidamente as informações 
desejadas.
Um exemplo muito simples de um banco de dados pode ser uma lista 
de nomes em ordem alfabética ou uma lista crescente de códigos 
numéricos, onde cada código representa um item do estoque.
Você pode armazenar informações no banco de dados de diferentes 
maneiras, conhecidas como modelos de banco de dados.
8
Os bancos de dados, normalmente, têm uma de duas formas básicas:
• Banco de dados de arquivo único ou arquivo simples.
• Banco de dados relacional ou estruturado de vários arquivos.
Um banco de dados de arquivo simples armazena dados em um 
arquivo de texto simples, com cada linha de texto, normalmente, 
contendo um registro. Delimitadores como vírgulas ou tabulações 
separam os campos. Um banco de dados de arquivo simples, como 
o nome indica, usa uma estrutura simples e, ao contrário de um 
banco de dados relacional, não pode conter várias tabelas e relações, 
segundo Elmasri.
Um banco de dados relacional contém várias tabelas de dados com 
linhas e colunas que se relacionam entre si, por meio de campos-
chave especiais. Esses bancos de dados são mais flexíveis do que 
as estruturas de arquivo simples e fornecem funcionalidade para 
leitura, criação, atualização e exclusão de dados. Os bancos de dados 
relacionais usam Structured Query Language (SQL), um aplicativo de 
usuário padrão que fornece uma interface de programação fácil para 
interação com o banco de dados.
O modelo de banco de dados relacional é o modelo de banco 
de dados mais amplamente usado. Usa relações e conjuntos 
para armazenar os dados. Na prática, parece que os dados são 
organizados em tabelas. Para acessar informações de um banco de 
dados, você, normalmente, precisa de um sistema de gerenciamento 
de banco de dados, ou simplesmente, de um SGBD (ORACLEc, 2021).
1.3 SGBD
Um SGBD é um software que permite a criação, definição e 
manipulação de banco de dados, permitindo aos usuários armazenar, 
9
processar e analisar dados com facilidade. O SGBD fornece uma 
ferramenta para realizar várias operações, como criar banco de 
dados, armazenar dados nele, atualizar dados, criar tabelas no banco 
de dados e muito mais.
O software SGBD funciona, principalmente, como uma interface entre 
o usuário final e o banco de dados, gerenciando simultaneamente 
os dados, o mecanismo do banco de dados e o esquema do banco 
de dados para facilitar a organização e a manipulação dos dados 
(ORACLEc, 2021).
Embora as funções do SGBD variem muito, os recursos e capacidades 
do SGBD de uso geral devem incluir: um catálogo acessível ao usuárioque descreve metadados, sistema de gerenciamento de biblioteca 
SGBD, abstração e independência de dados, segurança de dados, 
registro e auditoria de atividade, suporte para simultaneidade e 
transações, suporte para autorização de acesso, suporte de acesso 
de locais remotos, suporte de recuperação de dados SGBD em caso 
de danos e aplicação de restrições, para garantir que os dados sigam 
certas regras, segundo Elmasri, (2009).
O SGBD também fornece proteção e segurança para os bancos de 
dados, inclusive mantendo a consistência dos dados no caso de vários 
usuários. A Figura 1 apresenta uma organização onde temos o banco 
de dados sendo gerenciado pelo SGBD.
10
Figura 1–Sistema de gerenciamento de banco de dados
Fonte: elaborada pelo autor.
Basicamente, existem dois tipos de SGBDs: relacionais e não relacionais, 
conhecidos mais por, respectivamente, SQL e NoSQL. Diferem em 
termos de recuperação, distribuição e processamento de dados. 
Veremos estes tipos de SGBDs a seguir.
1.3.1 Bancos de Dados Relacionais (SGBDR)
Como o SQL é o núcleo desses sistemas, esse tipo de banco também é 
chamado de SQL. Em SGBDR, os dados aparecem como tabelas de linhas 
e colunas com uma estrutura rígida e dependências bem definidas.
Devido à estrutura integrada e ao sistema de armazenamento de dados, 
os bancos de dados SQL não requerem muito esforço de engenharia 
para torná-los bem protegidos. São uma boa escolha para construir e 
dar suporte a soluções de software complexas, onde qualquer interação 
tem uma série de consequências. Um dos fundamentos do SQL é 
a conformidade com ACID (atomicidade, consistência, isolamento, 
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
11
durabilidade). A conformidade com ACID é uma opção preferida se você 
criar, por exemplo, aplicativos de comércio eletrônico ou financeiros, 
onde a integridade do banco de dados é crítica, segundo Elmasri, (2009).
No entanto, a escalabilidade pode ser um desafio com bancos de dados 
SQL. O dimensionamento de um banco de dados SQL entre vários 
servidores (dimensionamento horizontal) exige esforços adicionais de 
engenharia, sendo um ponto fraco deste tipo de banco. Em vez disso, os 
bancos de dados SQL são, geralmente, escalados verticalmente, ou seja, 
adicionando mais poder de computação a um servidor.
Entre os principais bancos de dados SQL, destacam-se: SQL Server, 
Oracle, MySQL, MariaDB e PostgreSQL.
1.3.1 Bancos de Dados Não Relacionais (NoSQL)
Como esses bancos de dados não estão limitados a uma estrutura de 
tabela, são chamados de NoSQL. Este tipo de sistema de gerenciamento 
de banco de dados é considerado orientado a documentos. Dados não 
estruturados, como artigos, fotos, vídeos, publicações em redes sociais, 
áudios e outros, são coletados em um único documento. Os dados são 
simples de consultar, mas nem sempre são classificados em linhas e 
colunas como em um banco de dados relacional. Os bancos de dados 
não relacionais ou NoSQL,geralmente, são escalados horizontalmente 
com a adição de novos servidores (ELMASRI, 2009; ORACLEc, 2021).
Como os bancos de dados NoSQL permitem reservar vários tipos de 
dados juntos e escaloná-los, crescendo em torno de vários servidores, 
este tipo de banco está a cada dia se tornando mais popular, sendo 
utilizado por grandes nomes, como Facebook, Netflix, Twitter, Google, 
entre outros.
Os bancos de dados NoSQL são definidos em quatro tipos:
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
12
• Banco de dados chave-valor: têm uma estrutura de dados 
de dicionário, que consiste em um conjunto de objetos que 
representam campos de dados. Cada objeto recebe uma chave 
exclusiva. Para recuperar dados armazenados em um determinado 
objeto, precisa usar uma chave específica. Por sua vez, você obtém 
o valor (ou seja, dados) atribuído à chave. Esse valor pode ser 
um número, uma string ou até mesmo outro conjunto de pares 
de chave-valor. Geralmente, são bancos de dados in-memory. 
Principais sistemas de banco de dados deste tipo: Riak, Redis, 
Amazon DynamoDB.
• Banco de dados de documentos: são repositórios que podem ser 
representados nos formatos XML, JSON, BSON, que consistem em 
conjuntos de pares do tipo chave-valor para armazenamento dos 
dados. Esses documentos são unidades básicas de dados que você 
também pode agrupar em coleções (bancos de dados), com base 
em sua funcionalidade. Principais sistemas de banco de dados 
deste tipo: MongoDB, CouchDB e Elasticsearh.
• Banco de dados colunar: os dados são armazenados e agrupados 
em colunas armazenadas separadamente em vez de linhas. Esses 
bancos de dados organizam as informações em colunas que 
funcionam de forma semelhante às tabelas dos bancos de dados 
relacionais. Principais sistemas de banco de dados deste tipo: 
Cassandra e CosmoDB.
• Banco de dados baseado em grafos: usam uma representação 
flexível de grafos para gerenciar dados, consistindo em 
três elementos: o vértice ou nó (em comparação ao SQL, é 
como se fosse uma linha em um SGBD), aresta (representa 
o relacionamento entre dois nós), a propriedade (as arestas 
possuem propriedades, o que permite organizar os vértices). 
Principais sistemas de banco de dados deste tipo: Neo4J, ArangoDB 
e OrientDB.
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
Machine
Realce
13
1.4 Microsoft SQL Server
O Microsoft SQL Server é um dos líderes de mercado em tecnologia 
de gerenciamento de banco de dados. Trata-se de SGBDR que oferece 
suporte a vários aplicativos, incluindo BI (Business Intelligence), 
processamento de transações e análises.
O SQL Server segue uma estrutura de tabela baseada em linhas, 
permitindo a conexão de dados e funções enquanto mantém a 
segurança e consistência dos dados.
O Microsoft SQL Server também permite uma instalação simples 
e atualizações automáticas, personalização para atender às suas 
necessidades de negócios e manutenção simples de seu banco de 
dados.
1.4.1 Gerência de dados
Um banco de dados SQL é composto por um ou mais arquivos de dados 
(.mdf/.ndf) e um arquivo de log de transações (.ldf). Os arquivos de 
dados contêm esquema e dados, e o arquivo de log contém alterações 
ou inserções recentes. Os dados são organizados por páginas (como um 
livro), cada página tem 8 KB e são gerenciados quanto a leitura, escrita e 
atualizações (MICROSOFT, 2019).
De acordo com o site oficial, uma página é a unidade de armazenamento 
fundamental do SQL Server. O SQL Server acessa os dados puxando 
toda a página de 8 KB do disco para a memória. As páginas permanecem 
temporariamente na memória até que não sejam mais necessárias. 
Amiúde, a mesma página será modificada ou lida com frequência, pois o 
SQL funciona com o mesmo conjunto de dados (MICROSOFT, 2019).
O SQL altera os dados por meio de exclusão ou modificação, ou 
gravando novos dados. Todas as modificações são gravadas no log de 
14
transações (que fica no disco onde é seguro), no caso do servidor SQL 
perder energia antes de gravar os dados de volta no disco (MICROSOFT, 
2019).
A página de 8 KB é gravada de volta no disco depois de não ser usada 
por um determinado período. Depois que uma transação é gravada 
no disco (arquivo .mdf / .ndf), é marcada como gravada no log de 
transações. Em caso de queda de energia, o SQL pode recuperar as 
transações concluídas que não foram gravadas e adicioná-las aos 
arquivos do banco de dados (.mdf e .ndf) quando voltar a operar.
1.4.2 Edições SQL Server
Existem várias edições do SQL Server, dependendo do tamanho 
dos bancos de dados e qual a sua finalidade. Algumas edições são 
(MICROSOFT, 2019):
• Enterprise: para grandes organizações com requisitos complexos, 
a Enterprise Edition pode gerenciar bancos de dados de até 524 PB 
(Petabytes–1000 terabytes) ea quantidade de memória e núcleos 
de CPU é limitada apenas pelo sistema operacional em que está 
sendo executado.
• Standard: esta é a edição para empresas que possuem um banco 
de dados de tamanho razoável, 10 GB ou mais, ou se muitas 
pessoas se conectarem a ele. Possuí um limite de 128 GB de 
memória, mas também pode gerenciar bancos de dados de até 
524 PB.
• Web: projetado como uma maneira mais econômica de gerenciar 
bancos de dados para sites da web.
• BI (Business Intelligence): semelhante ao SQL Standard, mas 
com mais ferramentas analíticas e com propósito específico para 
Business Intelligence.
15
• Workgroup: disponível apenas até o SQL 2008, que agora está em 
fim de vida. Projetado para aplicações de pequenas empresas.
• Express: SQL Express é muito comum para pequenas e médias 
empresas. Embora suporte apenas bancos de dados de até 10 
GB e possa usar apenas 1 GB de memória e 1 núcleo de CPU, é 
uma licença gratuita da Microsoft, portanto, muitos aplicativos 
destinados a pequenas e médias empresas aproveitarão as 
vantagens do SQL Express. É uma maneira muito econômica de 
fornecer um mecanismo de banco de dados robusto e confiável 
para pequenas empresas, além de ser a versão escolhida por 
instituições de ensino.
Durante os estudos, utilizaremos o SQL Server 2019 Express.
1.5 Oracle
Um dos sistemas de banco de dados mais populares em todo o mundo, 
a Oracle, é confiável para algumas das maiores empresas em operação. 
Com muitas versões diferentes do banco de dados Oracle lançadas, 
a Oracle oferece recursos inovadores em muitas áreas, incluindo 
gerenciamento, desempenho, segurança e desenvolvimento (ORACLE, 
2018a).
Os administradores e desenvolvedores de banco de dados podem 
usar facilmente este sistema de banco de dados para criar aplicativos 
inovadores para suas operações de negócios. A marca Oracle 
é bem conhecida por sua dedicação contínua em pavimentar o 
desenvolvimento futuro de recursos atualizados para melhor 
auxiliar empresas, pequenas e grandes, em suas necessidades de 
gerenciamento de dados.
O banco de dados Oracle pode ser implantado localmente, em nuvem 
ou em uma configuração híbrida, sendo, principalmente, usado para 
16
armazenar dados para sistemas de processamento de transações 
online (OLTP) e vendido em várias edições com diferentes conjuntos de 
recursos e faixas de preço (ORACLE, 2018a).
Embora o banco de dados Oracle seja um data warehouse popular para 
empresas em todos os setores, você vai querer dar uma olhada mais de 
perto no custo da plataforma, na estratégia de bloqueio e nos requisitos 
de licenciamento antes de decidir exatamente como (e quando) usar o 
Oracle.
1.5.1 Arquitetura: armazenamento físico e lógico
A arquitetura do banco de dados Oracle depende de dois tipos de 
armazenamento: físico e lógico (ORACLE, 2018a).
• O armazenamento físico (em disco) contém todos os arquivos 
do banco de dados. Estruturas de armazenamento lógico, como 
espaços de tabela, segmentos, extensões e blocos aparecem no 
disco, mas não fazem parte do conjunto de dados.
• O armazenamento lógico ajuda os usuários a localizar dados 
específicos e ajuda a melhorar a eficiência do processo de 
recuperação, permitindo um sistema modular de armazenamento 
de dados no qual a capacidade pode ser ajustada sem afetar o 
desempenho.
Para entender a diferença entre os dois tipos de armazenamentos, 
utilizaremos como exemplo um livro. O livro é impresso em papel, ou 
seja, trata-se de um armazenamento físico, porém, existem informações 
adicionais, como o número do capítulo, número da página e notas de 
rodapé, que ajudam os leitores a navegar pelo livro e seu conteúdo, isso 
seria o armazenamento lógico.
Observe, então, que o armazenamento lógico se refere a uma 
informação contextual que aparece no livro, porém, que não faz parte 
17
da história do livro. Pelo contrário, trata-se de um guia para ajudar o 
leitor a encontrar informações específicas ou se localizar.
1.5.2 Arquitetura: objetos
Compreender a diferença entre o armazenamento físico e o 
armazenamento lógico é uma base para a compreensão de objetos de 
banco de dados.
As estruturas de armazenamento lógico diferem dos objetos de banco 
de dados em seu grau de visibilidade. Enquanto as estruturas lógicas 
de armazenamento residem no banco de dados para ajudar a organizar 
os dados, os objetos do banco de dados consistem em representações 
conceituais dos dados (ORACLE, 2018a).
Exemplos de objetos de banco de dados incluem linhas, tabelas, índices 
e visualizações que exibem dados.
Os objetos de banco de dados representam a visão lógica dos dados 
armazenados em arquivos de vários locais. Para conseguir isso, os 
objetos de banco de dados contam com estruturas de armazenamento 
lógico, que localizam os dados de destino.
1.5.3 Arquitetura: banco de dados e instâncias
O termo banco de dados é, geralmente, usado quando nos referimos 
ao banco de dados e à instância como um todo. Entretanto, é mais 
preciso usar este termo ao se referir especificamente ao disco físico ou 
armazenamento de arquivo que contém os dados e metadados. Por 
outro lado, uma instância são os processos e a memória reservados para 
acessar as informações no banco de dados.
18
Os bancos de dados existem no armazenamento físico (disco, 
por exemplo), enquanto as instâncias residem na memória e são 
executadas como processos. Estruturas de memória armazenam dados 
e metadados. Os processos ajudam a executar o banco de dados, 
permitem a comunicação entre vários componentes e mantêm os dados 
entre a memória e o disco sincronizados(ORACLE, 2018a).
1.5.4 Edições Oracle
A Oracle possui quatro edições de seu banco de dados, cada uma com 
seus preços e características diferentes (ORACLE, 2020b):
• Enterprise Edition (EE): é a principal edição do Oracle, que 
possui uma vasta gama de ferramentas e recursos para grandes 
corporações.
• Standard Edition (SE): edição que possui as funções básicas 
de gerenciamento de banco de dados para pequenas e médias 
empresas, a um custo muito menor do que o EE.
• Standard Edition One (SEO): é uma edição indicada para 
pequenas empresas e possui um preço especial para servidores de 
um único processador.
• Oracle Express (OE): é a versão ideal para Database Administrator 
(DBA), ou Administrador de Banco de Dados, cientistas de dados, 
estudantes e para aqueles que estão tendo seu primeiro contato 
com a Oracle. Trata-se de um banco de dados com as mesmas 
funcionalidades e poder computacional que outras versões, 
entretanto, possui um processo de download e instalação mais 
simples e é gratuito.
Durante os estudos, utilizaremos o Oracle 18C Express.
19
Nesta unidade, você pode conhecer um pouco sobre o conceito de 
banco de dados e sobre os gerenciadores de banco de dados. Você 
também foi apresentado a dois conceitos: bancos de dados relacionais 
e banco de dados não relacionais ou NoSQL. Enquanto os bancos 
relacionais utilizam uma estrutura fixa como tabelas com colunas e 
linhas, os bancos NoSQL são mais flexíveis, podendo apresentar pelo 
menos quatro tipo de organizações: banco de dados chave-valor, banco 
de dados de documentos, banco de dados orientado a grafos e banco de 
dados orientados a colunas.
Por fim, você teve uma introdução sobre os dois principais 
gerenciadores de bancos de dados: o SQL Server e o Oracle Database.
Referências
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 4. ed. São Paulo: 
Pearson, 2009.
MICROSOFT. Guia de arquitetura de página e extensões. 2019. Disponível 
em: https://docs.microsoft.com/pt-br/sql/relational-databases/pages-and-
extents-architecture-guide?view=sql-server-ver15#:~:text=Conforme%20
mencionado%2C%20em%20SQL%20Server,de%20sistema%20sobre%20a%20
p%C3%A1gina. Acesso em: 31 ago. 2021.
ORACLEa. Oracle Database 18c Technical Architecture. 2018. Disponível em: 
https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/18/
technical-architecture/pdf/db-18c-architecture.pdf. Acesso em: 31 ago.2021.
ORACLEb. Oracle Database Editions. Disponível em: https://docs.oracle.com/cd/
E11882_01/license.112/e47877/editions.htm#DBLIC109. Acesso em: 31 ago. 2021.
ORACLEc. O que é SQL? Disponível em: https://www.oracle.com/br/database/what-
is-database/. Acesso em: 31 ago. 2021.
https://docs.microsoft.com/pt-br/sql/relational-databases/pages-and-extents-architecture-guide?view=
https://docs.microsoft.com/pt-br/sql/relational-databases/pages-and-extents-architecture-guide?view=
https://docs.microsoft.com/pt-br/sql/relational-databases/pages-and-extents-architecture-guide?view=
https://docs.microsoft.com/pt-br/sql/relational-databases/pages-and-extents-architecture-guide?view=
https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/18/technical-architectu
https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/18/technical-architectu
https://docs.oracle.com/cd/E11882_01/license.112/e47877/editions.htm#DBLIC109.
https://docs.oracle.com/cd/E11882_01/license.112/e47877/editions.htm#DBLIC109.
20
Transações
Autoria: Ariel da Silva Dias
Leitura crítica: Washington Henrique Carvalho Almeida
Objetivos
• Compreender o conceito de transação em um banco 
de dados.
• Relacionar as propriedades ACID com os bancos de 
dados relacionais.
• Compreender os casos de bloqueio entre 
transações.
21
1. Processamento de transações
Os analistas de negócios que trabalham em soluções de sistemas devem 
ter uma compreensão básica dos conceitos de banco de dados. Diversos 
sistemas de gerenciamento de banco de dados (SGBD) fazem parte de 
uma classe de sistemas chamados de sistemas OLTP (OnLine Transaction 
Processing).
Antes de estudarmos sobre o processamento de transações e as 
propriedades a elas relacionadas, poderemos entender o que é uma 
transação em um banco de dados no contexto de OLTP.
Resumidamente, uma transação representa uma série de operações 
realizadas em um SGBD em relação a um banco de dados de modo que, 
uma vez que a transação é concluída, os dados são deixados em um 
estado confiável e também consistente. Se alguma etapa da transação 
falhar, todas as etapas serão revertidas, ou seja, retrocedidas, de modo 
que a integridade dos dados possa ser mantida.
Um exemplo típico de transação seria um pedido de um cliente em 
uma loja virtual. Este pedido consiste em uma série de eventos como 
aceitação do pedido, manutenção dos dados no estoque, cobrança, 
entre outros. A principal característica é que todos estes eventos são 
tratados como um todo.
Como dito anteriormente, uma transação não pode permanecer em 
um estado intermediário incompleto, desse modo, outros processos 
não podem acessar os dados da transação até que a transação seja 
concluída ou tenha sido revertida após a falha. O processamento de 
transações é projetado para manter a integridade do banco de dados (a 
consistência dos itens de dados relacionados) em um estado conhecido 
e consistente.
22
Desse modo, considerado o exemplo acima, a transação (pedido do 
cliente) só será efetivada quando tudo (aceitação do pedido, atualização 
do estoque, comprovação do pagamento, entre outros) forem 
processadas em sua totalidade. Logo, se houver uma falha na aceitação 
do pedido ou na comprovação do pagamento, a transação não será 
efetivada.
Outro exemplo típico de transação ocorre quando você realiza 
uma transferência via PIX de sua conta para outra. Por exemplo, 
consideremos que Ana e Beatriz, duas amigas, ambas possuem o saldo 
de R$ 1.000,00 em suas contas bancárias. Ana vai transferir, de sua 
conta bancária, o valor de R$ 300,00 para a conta bancária de Beatriz. 
Essencialmente, o que deve ser feito na transação é:
• Retirar o valor 300 do saldo de Ana, atualizando este novo saldo.
• Somar o saldo atual de Beatriz com o valor 300, atualizando este 
novo saldo.
Um código simplificado é apresentado a seguir, exemplificando esta 
transação:
UPDATE conta SET saldo = saldo–300 WHERE cliente = ‘Ana’ 
UPDATE conta SET saldo = saldo + 300 WHERE cliente = ‘Beatriz’
Este código, apesar de ter duas linhas, representa apenas uma única 
transação. Desse modo, por exemplo, se o nome do cliente destinatário 
(Beatriz) estiver errado ou não existir no banco, a transação não será 
efetivada. Ana continuará com seu saldo anterior (ou seja, não terá 
o débito do valor R$ 300,00 em sua conta) e Beatriz não receberá o 
crédito.
Se a transação for finalizada com sucesso, ou seja, não houve falha em 
nenhuma instrução, o novo saldo das amigas será R$ 700,00 para Ana e 
R$ 1.300,00 para Beatriz.
23
As transações também podem ocorrer em outros ambientes, por 
exemplo, entre uma organização e sua equipe por meio do aplicativo de 
Recursos Humanos, em marketing, controle de produção e em outros 
lugares. Normalmente, mas nem sempre, esses tipos de aplicativos 
foram implementados sobre bancos de dados relacionais.
Os SGBDs foram desenvolvidos para oferecer suporte ao 
processamento de transações, entretanto, não são os únicos meios 
para o processamento de transações por motivos históricos e por 
motivos técnicos. Além de aplicativos transacionais baseados em dados 
puramente relacionais, os bancos de dados relacionais incorporaram 
XML e recursos orientados a objetos ao longo dos anos para que 
ambientes transacionais híbridos (que requerem o uso dessas 
tecnologias junto com dados relacionais) também possam oferecer 
suporte ao processamento de transações, embora XML puro e os bancos 
de dados orientados a objetos continuem a fazer parte do mercado de 
aplicativos especializados.
Acrescenta-se, ainda, que muitas empresas continuam a empregar em 
seus projetos os SGBDs Hierárquicos para OLTP. Isso ocorre devido 
às dificuldades de migrar para fora deste tipo de banco de dados ou 
porque esses tipos de bancos hierárquicos são muito eficientes para a 
carga de trabalho específica.
1.1 Propriedades ACID
Além do desempenho e outras considerações generalizadas, os 
principais requisitos para bancos de dados de processamento de 
transações são as chamadas propriedades ACID (Atomicidade, 
Consistência, Isolamento, Durabilidade), as quais garantem que as 
transações sejam processadas de forma confiável, segundo Elmasri 
(2009).
24
As transações ACID eram um grande negócio quando introduzidas 
formalmente, na década de 1980, em bancos de dados SQL monolíticos, 
como Oracle e IBM DB2. Bancos de dados NoSQL distribuídos populares 
da última década, incluindo Amazon DynamoDB e Apache Cassandra, 
inicialmente, focados em casos de uso de Big Data, não exigiam tais 
garantias e, portanto, evitaram implementá-los completamente. No 
entanto, as transações ACID tiveram um forte retorno nos últimos anos 
com o lançamento de bancos de dados distribuídos que têm suporte 
integrado para eles.
A seguir, vamos conhecer cada uma destas propriedades, segundo Elmasri 
(2009):
• Atomicity (atomicidade): garante que todas as operações em uma 
transação são tratadas como uma única unidade, que é totalmente 
bem-sucedida ou falha totalmente. No exemplo da conta bancária, se 
alguma das instruções falhar, toda a transação deve ser abortada e 
retrocedida.
• Consistency (consistência): garante que uma transação só pode levar o 
banco de dados de um estado válido para outro, evitando a corrupção 
de dados. Suponha, então, que a transação do exemplo anterior falhe 
na segunda instrução no momento de atualizar o saldo de Beatriz, 
não somando em sua conta os R$ 300,00 e a transação não seja 
revertida. Desse modo, o banco de dados ficará inconsistente, pois a 
soma do dinheiro de Ana e Beatriz, após a transação, não será igual à 
quantidade de dinheiro que tinham antes da transação.
• Isolation (isolamento): cada transação deve ocorrer 
independentemente de outras transações ocorrendo ao mesmo 
tempo. Em outras palavras, consultas e transações sempre são 
executadas em um determinado momento. Você pode consultar 
dados enquanto muitos outros usuários estão alterando dados e você 
não verá suas alterações, e não verãoas alterações uns dos outros. 
No exemplo do banco, considere que, ao mesmo tempo (no exato 
25
momento) que Ana está fazendo um PIX para Beatriz, o marido de 
Ana acessa a conta para ver o saldo. Se a transação de transferência 
ainda não foi finalizada, o saldo que o marido de Ana verá será R$ 
1.000,00, mesmo que a Ana tenha solicitado a transferência dos R$ 
300,00, afinal, a transação ainda não finalizou. Logo, a transação de 
transferência entre as amigas é isolada da transação de visualização 
de saldo realizada pelo marido de Ana.
• Durability (durabilidade): garante que os resultados da transação 
sejam armazenados permanentemente no sistema. As modificações 
devem persistir mesmo em caso de perda de energia ou falhas 
do sistema. No exemplo anterior, se a conta de Beatriz possui R$ 
1.300,00, essas informações não devem desaparecer em caso de 
falha do sistema, queda de energia ou falha de software.
Observe, então, que as propriedades ACID visam garantir que as transações 
dos bancos de dados sejam válidas, mesmo em caso de falhas ou 
interrupções de energia elétrica, falha de hardware, falha de software, entre 
outras.
1.2 Estados de uma transação
Uma transação pode possuir cinco estados, conforme ilustra a Figura 1.
Figura 1–Estados da transação
Fonte: adaptado de GURU99 (2021).
26
Observe pela Figura 1 que, assim que é iniciada, a transação passa para 
o estado de ativa. Durante este estado são realizadas as operações de 
leitura ou gravação no banco de dados.
A partir do estado de ativa existem duas possibilidades (GURU99,2021):
• Uma transação pode ser abortada enquanto estiver no estado 
ativo. Quando isso ocorrer, passará para o estado de falha. Neste 
momento, para garantir as propriedades ACID, esta transação 
precisa ser revertida para desfazer o efeito de suas operações no 
banco.
• Assim que uma transação é finalizada, ou seja, assim que todas 
as instruções de READ e WRITE são executadas sem falhas, sai do 
estado de ativa e passa para o estado de parcialmente confirmada.
No estado de parcialmente confirmada, a transação será verificada 
sobre possíveis falhas de consistência. Novamente, existem duas 
possibilidades (GURU99,2021):
• Se a verificação resultar em falha, a transação vai para o estado de 
falha. Entra neste estado sempre que qualquer uma das instruções 
não for executada com sucesso.
• Por outro lado, se uma transação tem sua execução com sucesso, 
ou seja, se todas as suas alterações são aplicadas no banco de 
dados de modo permanente (de acordo com as propriedades 
ACID), então passa para o estado de confirmada ou commited.
Seja a partir do estado committed ou do estado de falha, a transação 
precisa ser finalizada. Logo, a transação alcançará este estado sempre 
que uma transação não pode mais ser reiniciada.
27
1.3 Concorrência e bloqueios
Bloqueios de banco de dados ocorrem para proteger recursos 
compartilhados durante as transações. Os bloqueios são salvaguardas 
para bancos de dados como um meio de:
• Observar um cenário de tudo ou nada para transações múltiplas e 
separadas.
• Preservar a consistência no estado do banco de dados.
• Isolar as transações de serem confirmadas até que a transação 
seja concluída.
• Salvar transações confirmadas, mesmo em caso de rescisão 
anormal.
Observe, então, que os bloqueios aderem às propriedades ACID de 
transação.
Antes de falarmos sobre bloqueios, poderemos entender porque são 
necessários.
1.3.1 Lost Update
O problema chamado Lost Update ou atualização perdida ocorre quando 
duas transações simultâneas tentam ler e atualizar os mesmos dados 
(COULOURIS, 2012). Veja o exemplo onde temos uma tabela chamada 
produto que armazena id, nome e itens em um estoque para um 
produto.
As informações contidas nessa figura são usadas em um sistema para 
exibir o número de itens em estoque para um determinado produto e, 
portanto, precisa ser atualizada cada vez que uma venda desse produto 
é feita.
28
Agora, considere as duas transações da Figura 2, onde transação 1 é o 
cliente 1 e transação 2 é o cliente 2, ambos estão realizando a compra ao 
mesmo tempo no site.
Figura 2–Exemplo de transações concorrentes
Fonte: elaborada pelo autor.
Observe, pela Figura 2, que a transação 1 inicia o processo de compra do 
produto X. Ao mesmo tempo, em outro lugar, transação 2 (do cliente 2) 
inicia o processo de compra do mesmo produto X.
A transação 1 lê os itens em estoque para o produto X, que, neste caso, é 
12. Um pouco depois (talvez milésimos de segundos), a transação 2 lê o 
valor da variável de itens para o produto X, que ainda é 12 (afinal, ainda 
não foi atualizado o valor de estoque deste produto). Na transação 2, o 
cliente compra três produtos X, pouco antes da transação 1 comprar 2 
produtos X.
Neste momento, quantos itens X temos no estoque? A transação 2, 
então, completará sua execução primeiro e atualizará a variável itens 
para 9, uma vez que o cliente comprou três dos 12 produtos X. A 
transação 2 finaliza. Como o cliente na transação 1 comprou dois itens, a 
variável itens valerá 10. Temos, então, uma inconsistência!
29
Como podemos resolver este problema de inconsistência? Uma das 
possíveis soluções é utilizarmos os bloqueios (locks).
1.3.2 Bloqueios
Para que você compreenda melhor, imagine três pessoas: André, 
Bruno e Carlos, todos são amigos e estão escrevendo um texto para 
a faculdade em um caderno. Como limitação, apenas um deles pode 
escrever no caderno por vez.
André, então, começa a escrever o texto. Como ele está com o caderno, 
bloqueia o acesso de Bruno e de Carlos à escrita, ficam aguardando.
Assim que finaliza, André passa o caderno para Bruno, que redige o 
texto, porém, agora, bloqueando a tentativa de acesso de Carlos ao 
caderno.
Carlos só terá acesso ao caderno quando Bruno concluir sua parte da 
escrita.
Quadro 1–Sequência de transações com bloqueio
Tempo André (transação 1) Bruno (transação 2) Carlos (transação 3)
1 Começa a escrever.
2 Deseja escrever.
Bloqueado por André.
3 Deseja escrever.
Bloqueado por André.
4 Finaliza a escrita.
Começa a escrever. Bloqueado por Bruno.
8 Finaliza a escrita.
Começa a escrever.
9 Finaliza a escrita.
Fonte: elaborado pelo autor.
No quadro 1 é possível observar a sequência de ações, desde o tempo 
1 quando André começou a escrever o texto até a finalização de todos. 
30
Observe que Carlos permaneceu bloqueado enquanto André, e depois, 
Bruno, escreviam no caderno.
O segundo escritor deve esperar que o primeiro finalize seu processo de 
escrita, enquanto o terceiro escritor deve esperar que o segundo libere o 
caderno e permita escrever.
Os bloqueios em banco de dados, funcionam da mesma maneira que 
os bloqueios apresentados no Quadro 1, ou seja, evitam a gravação e 
atualizações simultâneas para manter a integridade dos dados.
Os bloqueios podem ocorrer de várias formas. Aparecem em níveis 
de acesso a um banco de dados, geralmente, durante atualizações de 
dados. São tipos de bloqueios que podem ocorrer:
• Bloqueio a nível de banco de dados: restringe a apenas uma 
sessão de banco de dados para aplicar as alterações nesse 
banco de dados. Este tipo de bloqueio raramente é visto, mas é 
amplamente aplicado durante a atualização do software.
• Bloqueio a nível de arquivo: bloqueia os arquivos do banco de 
dados, evitando alterações em uma tabela inteira, em partes dela 
ou em outra tabela. Este é o método menos preferido de bloqueio, 
pois pode causar bloqueio não intencional.
• Bloqueio a nível de tabela: bloqueia uma tabela inteira e evita 
que as propriedades da tabela e também suas linhas sejam 
modificadas ou atualizadas por outros usuários.
• Bloqueio a nível de coluna: bloqueia uma coluna ou várias delas 
dentro de uma tabela. Isso, geralmente, não é oferecido por 
sistemas de banco de dados, pois requer muitos recursos para ser 
aplicado.
• Bloqueio a nível de linha: este é o tipo mais comum de bloqueio, o 
qual bloqueia uma linha de uma tabela.
31
Resumidamente, o bloqueioocorre quando qualquer processo acessa 
uma parte dos dados onde há uma chance de que outro processo 
simultâneo também necessita acessar esta mesma parte dos dados ao 
mesmo tempo. Ao bloquear estes dados, garantimos que somos capazes 
de agir sobre eles da maneira que esperamos.
Por exemplo, se lemos os dados, geralmente, gostamos de garantir que 
lemos os dados mais recentes. Se atualizarmos os dados, precisamos 
garantir que nenhum outro processo os atualize ao mesmo tempo.
1.3.3 Deadlock
Embora seja baseado nos mesmos princípios, os deadlocks são 
diferentes do bloqueio. Quando ocorre uma situação de deadlock, não 
há bloqueador principal identificável, pois ambas as sessões implicam 
em bloqueios incompatíveis em objetos que a outra sessão precisa 
acessar. É uma corrente de bloqueio circular (COULOURIS,2012).
Para melhor compreensão, voltemos à situação apresentada no Quadro 
1 quando os colegas estavam escrevendo no mesmo caderno, porém, 
adicionaremos mais complexidade.
Digamos que para que André possa escrever no caderno, precisa ler um 
livro chamado Banco de Dados, porém, não importa o motivo, o Bruno 
já está lendo este livro e adquiriu um bloqueio exclusivo, ou seja, está 
bloqueando um livro que André precisa ler. Lembre-se também de que o 
Bruno está aguardando André entregar a ele o caderno para que possa 
escrever.
Nesse caso, estamos na situação representada pela Figura 3 a seguir.
32
Figura 3–Exemplo de deadlock
Fonte: elaborada pelo autor.
Observe, pela Figura 3, que André está bloqueando o acesso ao caderno, 
porém, necessita do livro, que está bloqueado por Bruno. Por outro lado, 
Bruno necessita do caderno, mas este está com André, que só liberará 
quando tiver acesso ao livro.
Para que haja o deadlock como o apresentado na figura, as 
quatro condições a seguir devem ser mantidas simultaneamente 
(TANENBAUM,2007):
• Exclusão mútua: alguns recursos envolvidos não podem ser 
usados por mais de um processo ao mesmo tempo (um recurso 
pode ser mantido apenas por um processo). Isso significa que se 
um dado ou tabela estiver sendo usado por qualquer processo 
e algum outro processo vier a requerê-lo, terá que aguardar a 
liberação dos recursos. No exemplo dos colegas, o caderno não 
pode ser usado pelo André e pelo Bruno ao mesmo tempo.
• Sem preempção: se um processo está mantendo um recurso, 
então seus recursos não podem ser retirados à força dele. No 
33
exemplo, Bruno necessita do caderno, porém não pode retirar a 
força do André.
• Retenção e espera: o processo está retendo alguns recursos e 
aguardando outros recursos. No exemplo, Bruno está retendo o 
recurso livro e aguarda o caderno, por outro lado, André retém o 
caderno e aguarda a liberação do livro.
• Espera circular: o processo está aguardando o recurso que está 
sendo retido pelo próximo processo e isso forma uma cadeia de 
espera. No exemplo acima, o André e o Bruno estão formando 
uma cadeia e aguardando que o recurso seja liberado um pelo 
outro, formando uma espera circular.
A principal característica do deadlock é que, para acabar o deadlock, 
basta que apenas uma das quatro condições falhe ou não exista.
Nesta aula, começamos estudando os conceitos de transações. Vimos 
que existem quatro propriedades que as transações devem seguir 
que são a Atomicidade, Consistência, Isolamento e Durabilidade. Em 
seguida, vimos que as transações podem sofrer concorrências, o 
que impacta diretamente nas propriedades ACID, principalmente, na 
consistência. Por fim, vimos que o uso de bloqueios permite eliminar 
ou ao menos evitar questões, como lost update, porém, dependendo 
da implementação, as transações podem entrar em deadlock, que é 
quando um processo bloqueia um recurso que é requerido por outro 
em uma espera circular.
Referências
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed systems: concepts and 
design. 5. ed. England: Addison Wesley, 2012.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 4. ed. São Paulo: 
Pearson, 2009.
34
GURU99. DBMS Transaction Management: What are ACID Properties? Disponível 
em: https://www.guru99.com/dbms-transaction-management.html> Acesso em: 31 
ago. 2021.
TANENBAUM, A. S.; STEEN, M. V. Sistemas distribuídos: princípios e paradigmas. 2. 
ed. São Paulo: Pearson, 2007.
35
Backup e recuperação de 
banco de dados
Autoria: Ariel da Silva Dias
Leitura crítica: Washington Henrique Carvalho Almeida
Objetivos
• Compreender o conceito de disponibilidade de 
dados. 
• Relacionar a disponibilidade de dados com o 
processo de backup e restauração de dados.
• Conhecer os tipos de backups que podem ser 
executados em um banco de dados.
36
1. Disponibilidade de dados
Não há dúvida de que a maior preocupação para DataBase 
Administrators (DBAs), ou Administradores de Banco de Dados, e outros 
profissionais de banco de dados é a disponibilidade. Se o banco de 
dados estiver indisponível, você sabe exatamente o resultado: consultas 
lentas. Considere, ainda, que há a questão do tempo de inatividade 
resultante, capacidade de recuperação e perda de dados. Quando 
o servidor está inativo, esses tipos de problemas rapidamente têm 
precedência sobre todos os demais.
1.1 Erro, falha e falta
Quando falamos que um sistema apresentou um erro, estamos dizendo 
que o que ocorreu foi decorrente de uma ação humana. Os erros 
podem ser cometidos por qualquer pessoa da equipe de Tecnologia 
da Informação (TI) durante as diferentes fases do desenvolvimento de 
software. As pessoas da equipe cometem erros devido à pressão de 
tempo de entrega, requisitos pouco claros ou insuficientes, suposições, 
complexidade de requisitos e vários outros motivos.
Desse modo, o erro produz como resultado um defeito, que pode ser 
denominado como falta. Em alguns casos, o defeito é sinônimo de 
bug. Entretanto, o bug, geralmente, se refere à falha no ambiente de 
desenvolvimento e o defeito se refere à falha no ambiente de teste. 
Um defeito ocorre quando o comportamento do software real não é o 
mesmo que a expectativa do cliente, segundo Laplante (2001).
Sendo assim, como consequência de um defeito, temos a falha. É dito 
que o software possui uma falha quando não possui o comportamento 
conforme o esperado. As condições do ambiente em que o software 
deve executar podem causar a falha. A condição do ambiente pode 
37
incluir magnetismo, campos eletrônicos, radiações, poluições, efeitos 
químicos, e assim por diante.
Note que o defeito ou falta é um nível de percepção interna do sistema, 
enquanto a falha se refere a fatores externos ao sistema.
Desse modo, quando um programador desenvolve um sistema e escreve 
um comando if de modo errado, terá gerado um defeito ou falta, que, 
neste caso, foi causada pelo programador desatento. Se este comando 
if for executado, ou seja, foi necessário realizar a comparação entre dois 
valores no if, teremos um erro. Se o comportamento do erro for notado, 
poderemos dizer, então, que temos uma falha.
1.2 Perda de banco de dados
Um banco de dados é o meio de organizar as informações para que 
possam ser facilmente gerenciadas, atualizadas e recuperadas. O 
usuário não pode acessar diretamente o banco de dados, logo, é 
necessário um Sistema de Gerenciamento de Banco de Dados (SGBD), 
que fornece acesso e uma maneira de gerenciar os dados.
Entre as diversas funções de um SGBD, uma é cuidar da perda de 
dados, afinal, perder um banco de dados significa perder os dados a ele 
associado. Em poucas palavras, se uma empresa perder seus bancos 
de dados por uma série de razões, sem backups armazenados, é justo 
presumir que, provavelmente, perderá os dados também.
O processo de recuperação de banco de dados não é totalmente 
diferente da recuperação de dados. Da mesma forma, os motivos para 
uma perda de banco de dados também não são muito diferentes dos 
motivos para a perda de dados. Então, antes de vermos a recuperação 
de dados ou de banco de dados, analisaremos os cenários que podem 
levar à perda do banco de dados.
381.2.1 Falha de energia
Falhas de energia podem levar a falhas de hardware. Os componentes 
de hardware afetados podem ser cabos, fontes de alimentação 
ou dispositivos de armazenamento. A falha pode tornar os dados 
inacessíveis ou simplesmente resultar em perda de dados. Seria 
necessário isolar a área afetada antes de investigar se o banco de dados 
foi afetado pela falta de energia.
1.2.2 Falha de mídia (disco)
Embora as falhas de energia possam levar à falha de disco, também 
podem falhar devido a danos físicos ou a uma falha lógica. De qualquer 
modo, isso levará à perda de um banco de dados, a menos que um 
serviço de backup seja executado no disco regularmente. A falha do 
disco é, provavelmente, uma das causas mais comuns de perda de 
dados.
As falhas de mídia, geralmente, deixam os sistemas de banco de dados 
indisponíveis por várias horas até que a recuperação seja concluída, 
especialmente em aplicativos com dispositivos grandes e alto volume de 
transações.
A melhor maneira de evitar esse tipo de falha do banco de dados é 
proteger seus dados com proteção contra malware adequada e fazer 
backup de seus dados com frequência.
1.2.3 Falha humana
Embora a maioria dos processos seja automatizada, ainda existem 
muitas funções que precisam ser executadas manualmente. Um 
funcionário pode excluir acidentalmente alguns dados, ou então pode 
39
modificar os dados sem saber de uma forma que interrompa o SGBD de 
interagir com o banco de dados.
Quando o SGBD não consegue interagir com o banco de dados, causa 
um efeito cascata, pois os aplicativos de terceiros que dependem do 
SGBD para interagir com o banco de dados também perdem o acesso a 
ele.
Além da falha acidental, também temos a falha intencional, ou seja, 
um funcionário insatisfeito pode fornecer informações essenciais 
e confidenciais a estranhos, causando danos incalculáveis a uma 
organização. Se o funcionário tiver acesso ou obtiver acesso não 
autorizado a sistemas ou aplicativos, pode injetar um vírus ou deletar 
dados para interromper as operações do dia a dia da empresa.
1.2.4 Falha de software
As empresas que usam infraestruturas de TI tradicionais correm mais 
risco de corrupção de software do que aquelas que dependem de 
serviços baseados em nuvem. Enquanto os fornecedores de nuvem 
fornecem flexibilidade e escalabilidade de recursos, os ambientes de TI 
tradicionais têm conjuntos fixos de recursos de hardware que atualizam 
manualmente.
Quando o número de usuários finais em uma empresa aumenta, os 
aplicativos que utilizam os mesmos recursos são divididos ainda mais 
entre os novos usuários, causando problemas, como travamento de 
sistemas operacionais e aplicativos durante a utilização do software. 
O travamento faz com que o usuário final perca os dados não salvos. 
Quando ocorre de maneira repetida, o travamento pode causar sérios 
danos, especialmente se o usuário estiver trabalhando em um banco de 
dados.
40
1.2.5 Vírus
Uma empresa não pode operar com segurança sem o uso de uma boa 
solução de segurança. Os ataques cibernéticos são a maior ameaça que 
uma empresa enfrenta hoje e é imperativo que a solução de segurança 
execute varredura em tempo real. Dependendo do tipo de vírus, pode 
roubar, corromper, modificar e até mesmo excluir o banco de dados 
completo.
1.2.6 Desastres naturais
Desastres naturais, como terremotos ou tsunamis, podem destruir toda 
a infraestrutura. Nesse caso, não há nenhuma maneira de encontrar, 
muito menos recuperar os dados.
A recuperação de desastres é uma solução que não só ajuda a restaurar 
os dados, mas também garante que a empresa enfrente o tempo 
mínimo de inatividade conforme acordado no Service Level Agreement 
(SLA), ou Acordo de Nível de Serviço. Sem uma solução de recuperação 
de desastres, uma empresa pode até ter que recorrer ao encerramento 
de seus negócios após o desastre.
1.3 Métodos de backup e restauração de dados
Até aqui, vimos sobre os tipos de falhas que podem ocorrer em um 
sistema de banco de dados. Agora, veremos o conceito de backup e 
alguns dos principais métodos de proteção de dados.
Backup é o processo de criação de uma cópia dos dados para proteção 
contra exclusão acidental ou mal-intencionada, corrupção, falha de 
hardware, ataques de ransomware, entre outros. Os backups podem ser 
criados localmente, externamente ou ambos. Entretanto, um backup 
de dados externo é uma parte fundamental de qualquer plano de 
continuidade de negócios para recuperação de desastres.
41
Restaurar é o processo de recuperar dados de um backup. Em poucas 
palavras, significa copiar dados da mídia de backup para um dispositivo 
existente ou para um novo dispositivo, ou então, copiar dados da nuvem 
para um dispositivo local ou, por fim, realizar uma cópia de uma nuvem 
para outra.
Recuperação se refere ao processo de restauração de dados 
e operações (por exemplo, retornar um servidor à ordem de 
funcionamento normal após falha de hardware). Os produtos voltados 
para a recuperação rápida de dados e operações são, normalmente, 
chamados de soluções de continuidade de negócios e recuperação de 
desastres, ou Business Continuity and Disaster Recovery (BCDR).
A tecnologia BCDR ajuda as organizações a evitar perda de dados e 
minimizar o tempo de inatividade durante interrupções significativas.
Os tempos de restauração e recuperação podem variar drasticamente, 
dependendo do formato do backup e dos métodos de recuperação de 
dados escolhidos. Além disso, as necessidades de restauração também 
variam (por exemplo, restaurar um único arquivo em vez de um servidor 
inteiro). Finalmente, os dados críticos podem residir em estações 
de trabalho, servidores locais e na nuvem. Essas são considerações 
importantes ao selecionar uma solução de backup e recuperação.
1.3.1 Backup em fita ou em disco
O backup em fita é um dos mais antigos e resiste em atividade desde 
a década de 1960. A fita ainda é comumente usada para backup, 
arquivamento de sistemas corporativos de grande porte e até mesmo 
para armazenamento em nuvem a longo prazo. Os principais benefícios 
da fita são:
• Grande capacidade.
42
• Baixo custo.
• Backup externo de dados.
Por outro lado, o backup em disco surgiu na década de 1990 e, já no 
início dos anos 2000, cresceu em popularidade, afinal, oferecia backup 
e recuperação muito mais rápidos do que os sistemas de fita. Além 
da velocidade, o backup de disco também permite que os usuários 
recuperem arquivos individuais sem a necessidade de primeiro 
restaurar um conjunto de dados inteiro.
As soluções tradicionais de backup em disco têm a capacidade de 
transferir dados para fita ou nuvem para recuperação de desastres e/
ou arquivamento. No entanto, restaurar um volume grande de dados (o 
conteúdo de um servidor inteiro), de uma fita externa ou da nuvem, é 
lento. Usando métodos tradicionais de backup, a recuperação pode levar 
horas ou até dias. Durante esse tempo, as operações de negócios ficam 
seriamente comprometidas, resultando em perda de receita.
1.3.2 Backup em nuvem
Temos três possibilidades de backup em nuvem, segundo Docave (2021):
• Backup direto para a nuvem: com este tipo, os backups de 
arquivos externos são copiados diretamente para a nuvem, 
evitando a necessidade de um dispositivo local.
• Backup de nuvem para nuvem: é o processo de copiar dados de 
uma nuvem para outra nuvem, por exemplo, entre a nuvem da 
Amazon e a nuvem da IBM, ou então entre uma nuvem pública 
para uma nuvem privada.
• Backup SaaS (Software como Serviço): backup de dados criados em 
aplicativos SaaS, como Microsoft 365 ou Google G Suite.
43
Muitas organizações acreditam que, como os dados SaaS existem na 
nuvem, não há mais necessidade de backup. Isso, no entanto, não é 
verdade. Os dados criados em aplicativos SaaS são tão vulneráveis 
à exclusão acidental ou mal-intencionada e ataques de ransomware 
quanto os dados locais. O backup e a recuperação na computação em 
nuvem ainda estão evoluindo e continuarão a se desenvolver à medidaque mais empresas migrarem cargas de trabalho para a nuvem.
A tecnologia de continuidade de negócios e recuperação de desastres 
(BCDR) ajuda as organizações a evitar a perda de dados e minimizar o 
tempo de inatividade durante interrupções significativas.
Existem vários tipos de backups, eentre eles, destacam-se: backup 
completo, incremental, backup diferencial e backup completo sintético 
(TTGTMEDIA, 2021). Vamos analisar cada um deles a seguir.
1.3.3 Backup completo
O backup completo faz backup de todo o conteúdo selecionado, 
incluindo também os arquivos de log de transações. Esta opção requer 
mais espaço para armazenamento, pois cada arquivo de backup pode 
ser grande, dependendo do tamanho do seu ambiente. Ao contrário 
dos backups incrementais e diferenciais, todos os backups completos 
são independentes uns dos outros e não dependem de outros arquivos 
de dados de backup. Cada um dos backups é abrangente, portanto, as 
tarefas de backup completo demoram mais para ser concluídas dentre 
as três opções disponíveis (OMELCHENKO, 2015a).
A Figura 1 apresenta um exemplo de como são os backups completos. 
Observe que o primeiro backup pode ter sido executado em uma 
segunda-feira, o segundo em uma terça-feira, e assim por diante.
44
Figura 1–Backup completo
Fonte: adaptado de (TTGTMEDIA,2021)
Por consumir muito espaço de armazenamento, muitas empresas optam 
por realizar este tipo de backup mensalmente ou quinzenalmente. Desse 
modo, outros tipos de backup são necessários.
1.3.4 Backup incremental
O backup incremental foi desenvolvido com o propósito de aumentar 
a velocidade de backup, bem como diminuir o tamanho deste backup, 
ocupando menos espaço de armazenamento quando comparado ao 
backup completo. Para isso, esta técnica apenas realiza o backup apenas 
dos dados que foram recentemente alterados, ou seja, aqueles que 
foram alterados desde o último backup completo, segundo Docave 
(2021).
Por exemplo, suponha que, em uma sexta-feira, foi realizado o backup 
completo do sistema. Na semana seguinte, foram realizados backups 
incrementais. O backup de segunda-feira foi executado às onze horas da 
noite, logo, este backup conterá apenas os dados que foram modificados 
desde o último backup completo de sexta-feira. O backup de terça-feira 
conterá apenas os dados que foram modificados desde segunda-feira, e 
assim por diante. A Figura 2 ilustra este tipo de backup.
45
Figura 2–Backup incremental
Fonte: adaptado de TTGTMEDIA (2021).
Observe, pela Figura 2, que o primeiro backup é um exemplo do backup 
realizado na sexta-feira, é o backup completo. O segundo backup é 
aquele que foi gerado na segunda-feira, desde o último backup de sexta. 
O terceiro backup foi realizado a partir do último backup, que foi o de 
segunda-feira, e assim por diante.
Apesar de ocupar pouco espaço, este tipo de backup possui mais 
complexidade no processo de restauração. Vamos retomar o exemplo 
anterior. Supondo que estamos na quinta-feira e o DBA deseja restaurar 
o backup de quarta-feira. Primeiramente, deveria restaurar o backup 
completo da sexta-feira e, em seguida, restaurar o backup de segunda-
feira, depois o de terça-feira e, por fim, o backup de quarta-feira.
1.3.5 Backup diferencial
O backup diferencial e o backup incremental são muito parecidos, 
começa com a execução do backup completo, seguido de backups 
contendo apenas os dados que foram modificados.
46
A diferença marcante entre os dois é observada na mecânica deste 
backup. Lembre-se de que o backup incremental deve incluir apenas 
os dados modificados desde o último backup completo. De posse 
desta informação, veja na Figura 3 que o backup diferencial inclui todos 
os dados que foram modificados desde o último backup completo 
(OMELCHENKO,2015b).
Desse modo, considere o exemplo anterior onde foi realizado um 
backup completo em uma sexta-feira. Na segunda-feira foi realizado 
um backup diferencial, logo, tudo o que foi alterado de sexta-feira até 
a segunda será incluído no backup. No dia seguinte, terça-feira, foi 
realizado um novo backup diferencial. Neste backup, teremos todos os 
dados do último backup completo, ou seja, todos os dados de sexta-feira 
até o dia atual.
Figura 3–Backup diferencial
Fonte: adaptado de TTGTMEDIA (2021).
Observe, pela figura, que, primeiramente, foi executado o backup 
completo. No exemplo anterior, é como se este fosse o backup de 
sexta-feira. O segundo backup foi realizado sobre os dados modificados 
desde o último backup completo. Observe que o terceiro backup foi 
feito também sobre todos os dados modificados desde o último backup 
completo. O mesmo ocorre com o quarto backup.
47
1.3.6 Backup completo sintético
O backup completo sintético envolve fazer o backup completo, que 
precede uma sequência de backups incrementais. Então, você pode 
dizer que isso é o backup incremental. Entretanto, aqui, há uma 
diferença. Neste tipo de backup, o servidor combina o backup completo 
com os dados dos backups incrementais. Como resultado, temos um 
backup completo sintético, que é igual a um backup completo executado 
da maneira tradicional.
Neste tema, começamos a compreender a diferença entre erro, falha e 
falta. Essencialmente, falta é uma condição que faz com que o sistema 
não execute sua função exigida; erro se refere a diferença entre a saída 
real e a saída esperada; e falha é a visão de que o comportamento 
externo está incorreto. Em seguida, vimos os tipos de falhas bem como 
pode compreender os diversos tipos de backups que podemos realizar 
em um sistema de banco de dados.
Referências
DOCAVE. Overview of Backup Types. Disponível em: https://avepointcdn.
azureedge.net/assets/webhelp/docave/platform-backup-and-restore/index.
htm#!Documents/overviewofbackuptypes.htm. Acesso em: 31 ago. 2021.
LAPLANTE, P. Dictionary of Computer Science Enginnering and Technology. New 
York: CRC, 2001.
OMELCHENKO, A. Full Backup. 2015a. Disponível em: https://sqlbak.com/academy/
full-backup. Acesso em: 31 ago. 2021.
OMELCHENKO, A. Differential Backup. 2015b. Disponível em: https://sqlbak.com/
academy/differential-backup. Acesso em: 31 ago. 2021.
TTGTMEDIA. Full vs. incremental vs. differential backup. Disponível em: https://
cdn.ttgtmedia.com/rms/onlineimages/whatis-pillar_full_incremental_differential_
backup_desktop.png. Acesso em: 31 ago. 2021.
48
Segurança de banco de dados
Autoria: Ariel da Silva Dias
Leitura crítica: Washington Henrique Carvalho Almeida
Objetivos
• Compreender o conceito de segurança de banco 
de dados.
• Diferenciar os conceitos de autenticação, 
autorização e controle de acesso.
• Estabelecer relação entre conceitos de segurança 
em banco de dados, especificamente RBAC e 
ABAC.
49
1. Segurança de banco de dados
Os bancos de dados são um dos componentes mais sensíveis à 
segurança da infraestrutura de informações em qualquer organização. 
Isso ocorre porque são os guardiões do ativo mais importante de 
qualquer organização, ou seja, os dados. Todo banco de dados precisa 
de mecanismos de controle de acesso flexíveis, para evitar o acesso e a 
alteração não autorizada aos dados. Isso requer necessariamente:
• Autenticação de usuários (mais comumente implementado por 
meio de senhas).
• Autorização de cada tentativa de acesso a dados.
A segurança do banco de dados abrange uma variedade de controles 
de segurança projetados para proteger o Sistema de Gerenciamento 
de Banco de Dados (SGBD). Os tipos de medidas de segurança ao 
banco de dados que uma empresa pode usar, incluem a proteção da 
infraestrutura subjacente que hospeda o banco de dados (como a rede 
e os servidores), a configuração segura do SGBD e o controle de acesso 
aos próprios dados.
De acordo com Kim e Solomon (2014), esta segurança é obtida de 
acordo com o sucesso do emprego de três conceitos: autenticação, 
controle de acesso e autorização. Estes são três conceitos importantes 
e fundamentais de segurança, que, geralmente, são confundidos 
por muitos. A diferença entre eles, geralmente,não é entendida 
adequadamente e, às vezes, são considerados a mesma coisa ou os 
termos são usados de forma intercambiável.
Talvez isso ocorra porque os processos de autenticação, autorização 
e controle de acesso, geralmente, parecem ocorrer ao mesmo tempo 
da perspectiva do usuário final e como um único processo. Entretanto, 
50
pode ser extremamente importante entender a distinção ao gerenciar 
um sistema de banco de dados.
O Quadro 1 apresenta a relação entre estes três conceitos, divididos 
sobre o que cada um deles faz e o que eles protegem.
Quadro 1–Relação entre autenticação, controle 
de acesso e autorização
Categoria O que Protege de
Autenticação.
Confirma que a identidade é 
quem diz ser.
O mundo inteiro.
Controles de 
acesso.
Fornece autenticação/ validação 
adicional para acessar recursos 
específicos.
Credenciais 
comprometidas 
(roubadas).
Autorização.
Determina quais ações a 
identidade pode executar em 
recursos específicos.
Acidentes, 
credenciais 
comprometidas, 
especialistas 
maliciosos.
Fonte: elaborado pelo autor.
Observe que existem diferenças sensíveis entre cada um dos conceitos. 
Sendo assim, aqui, você terá um esclarecimento desses conceitos que 
são distintos e uma explicação de como são aplicados tipicamente em 
alguns cenários.
1.1 Autenticação
51
A autenticação é um processo pelo qual você verifica se alguém é quem 
afirma ser. Isso, geralmente, envolve solicitar ao usuário um nome 
de usuário e uma senha, mas pode incluir qualquer outro método de 
demonstração de identidade, por exemplo, um cartão inteligente, um 
número PIN, um código secreto enviado em uma carta na postagem, 
uma digitalização de impressão digital e reconhecimento facial, de 
acordo com Kim e Solomon (2014).
Para executar a autenticação, um usuário já deve ter uma conta 
criada em um sistema que possa ser interrogado pelo mecanismo de 
autenticação ou uma conta deve ser criada como parte do processo da 
primeira autenticação.
A saída do processo de autenticação, geralmente, é um resultado binário 
de sim ou não–o usuário é quem diz ser ou não é (um talvez seria 
tratado como um não).
Observe que o alguém, citado no primeiro parágrafo, pode não ser uma 
pessoa real. Por exemplo, um aplicativo que está tentando usar uma 
API de serviços web pode precisar usar autenticação para provar que 
é o aplicativo em questão. Desse modo, esse aplicativo pode fazer isso 
exatamente da mesma maneira que um usuário humano real provaria 
sua identidade.
1.2 Autorização
Autorização é o processo de estabelecer se o usuário (que já está 
autenticado) tem permissão para ter acesso a um recurso. Determina 
o que um usuário é e o que tem (ou não tem) permissão para fazer, 
conforme destaca Kim e Solomon (2014).
O nível de autorização para fornecer a um usuário é determinado 
examinando as propriedades adicionais (metadados) associadas à 
conta do usuário. Por exemplo, os dados associados a um usuário 
52
podem indicar se são membros de um determinado grupo, como 
Administradores ou Desenvolvedores. Outro exemplo, considere um 
sistema de TV por assinatura. Na autorização, o servidor do serviço pode 
indicar se o cliente pagou a assinatura para algum conteúdo pago ou 
podem indicar se ainda está dentro do período de 30 dias de um teste 
gratuito.
A autorização também inclui um componente de gerenciamento 
de autorização, responsável por fornecer a funcionalidade para 
criar as regras de autorização. Por exemplo, pode permitir que um 
administrador crie uma regra para permitir que outro usuário edite 
ou escreva dados em uma tabela. O gerenciamento de autorização, 
geralmente, usa grupos, funções, privilégios e permissões para definir 
essas regras.
A autorização responde a seguinte pergunta: dada uma identidade 
(verificada) de um usuário, a operação que está tentando realizar 
deve ser permitida? Por exemplo, Ana trabalha na equipe de recursos 
humanos de uma empresa, então precisa ter acesso aos registros 
de salários dos funcionários. E se ela trabalhasse, por exemplo, no 
departamento de gestão de estoque? Neste caso, não teria acesso aos 
salários dos funcionários.
Políticas de controle de acesso implementadas por um SGBD permitem 
que um administrador de banco de dados especifique a resposta precisa 
a esse tipo de pergunta, aplicando regras no nível do banco de dados.
1.3 Controle de acesso
Controle de acesso é o processo de impor a segurança necessária para 
um recurso específico, como salienta Kim e Solomon (2014).
Depois que soubermos quem é um usuário,que nível de autorização 
possui e a que devemos ou não dar acesso, precisamos impedir 
53
fisicamente ou logicamente esse usuário de acessar qualquer coisa que 
não possa. O controle de acesso pode ser visto como a combinação de 
autenticação e autorização, além de medidas adicionais, como restrições 
baseadas em relógio ou IP.
No contexto de uma aplicação Web ou de um SGBD, o controle de 
acesso pode ser implementado usando lógica sob medida, recursos 
de segurança da estrutura de desenvolvimento em uso, permissões de 
arquivo, listas de acesso ou muitos outros mecanismos.
As políticas de controle de acesso, em geral, baseiam-se nas noções de 
sujeito, objetos, operações e privilégios . Um sujeito é um ator que está 
tentando realizar uma ação em um objeto. Um objeto é um recurso 
que precisa ser protegido contra uso não autorizado. Uma operação é 
qualquer ação que um sujeito pode realizar em um objeto, e diferentes 
operações podem ser relevantes em diferentes tipos de objetos. Um 
privilégio é a permissão para um usuário realizar uma determinada 
operação em um objeto especificado (AFTAB, 2019).
No contexto de bancos de dados, os sujeitos podem ser usuários 
ou aplicativos. Os recursos podem ser de diferentes tipos e com 
granularidade variável, como bancos de dados, tabelas, colunas e assim 
por diante. No contexto desses recursos, as operações relevantes 
correspondem às ações familiares do banco de dados, como criar, 
modificar, atualizar e ler. Além disso, os bancos de dados, geralmente, 
oferecem suporte a ações administrativas, como desligar ou fazer 
backup do banco de dados.
O controle de acesso deve ser feito em dois níveis como apresentado 
por Kim e Solomon (2014):
• Físico: assim como nos filmes de espionagem onde o agente deve 
passar por vários seguranças (área protegida) para ter acesso a um 
determinado local e, uma vez dentro do espaço físico desejado, 
54
pode ter acesso a um sistema, um controle de acesso físico é 
feito por um crachá, cartão inteligente (smart card), entre outros. 
Sendo um funcionário, por meio deste controle físico, é possível ter 
acesso a área física interna destinada à sua permissão.
• Lógico: este controle de acesso é feito em nível de software. 
Um exemplo de controle de acesso lógico é dentro de uma 
organização, onde um usuário pode ter acesso a um determinado 
software ou conjunto de softwares. Pode-se ter restrições e 
monitoramento dos mesmos.
No exemplo apresentado anteriormente, se Ana realmente trabalhar no 
departamento de recursos humanos, precisará receber permissão para 
acessar a tabela do banco de dados que contém os registros de salários 
dos funcionários. Da mesma forma, Beatriz, uma desenvolvedora, pode 
ter acesso aos bancos de dados de teste, mas não aos de produção. O 
Quadro 1 apresenta um exemplo de uma entrada típica em uma lista de 
controle de acesso.
Quadro 1–Lista de controle de acesso
Usuário Recurso Permissão
Ana. salario_funcionarios Leitura e escrita.
Beatriz. banco_teste Leitura e escrita.
Fonte: elaborado pelo autor.
Observe que temos o recurso para a Ana e para Beatriz, bem como suas 
devidas permissões a determinado recurso. Entretanto, uma empresa, 
geralmente, possui muitos funcionários, então, torna-se complexo 
realizar este tipo de controle de acesso. Então, veremos o Controle de 
Acesso Baseado em Função.
55
1.3.1 Controle de Acesso Baseado em Função (RBAC)
As listas de controle de acesso por usuário setornam rapidamente 
incontroláveis quando temos muitos usuários. Aqui, entra o controle 
de acesso baseado em função (Role-Based Access Control RBAC). Definida 
de maneira simples, uma função é apenas uma coleção de privilégios 
(AFTAB, 2019).
Desse modo, em vez de definir privilégios para cada usuário individual, 
algumas funções podem ser definidas e os usuários podem ser 
atribuídos a funções. Isso é útil porque, na prática, os usuários podem 
ser classificados em grupos (com base em suas funções na organização), 
com requisitos de acesso a dados semelhantes para todos os usuários 
em um grupo. A Figura 1 apresenta um exemplo desta relação.
Figura 1–Controle de acesso baseado em função
Fonte: elaborada pelo autor.
Muitos bancos de dados também permitem que os usuários recebam 
várias funções, e uma função ativa pode ser assumida em qualquer 
conexão de banco de dados. Alguns bancos de dados também permitem 
definições hierárquicas de funções, em que uma função pode herdar 
todos os privilégios de uma ou mais funções, e esses privilégios 
herdados são adicionados aos privilégios explicitamente concedidos a 
essa função.
56
Como exemplo, as funções correspondentes a desenvolvedores, pessoal 
de contas, pessoal de recursos humanos, analistas de dados e assim por 
diante, podem ser definidas com os privilégios apropriados concedidos 
a cada uma dessas funções. Os usuários podem então receber uma ou 
mais funções (AFTAB, 2019).
Embora as políticas de controle de acesso baseadas em funções possam 
especificar políticas de acesso a dados em um nível granular, torna-se 
muito difícil manter essas políticas. Aqui, estão algumas dificuldades no 
gerenciamento de políticas RBAC (DAS,2018):
• Os dados da maioria das organizações são mantidos em vários 
bancos de dados, seja localmente e/ou na nuvem, diferentes tipos 
de bancos, como relacional, noSQL e data warehouses, cada um 
com seu próprio tipo de políticas de controle de acesso.
• Novos aplicativos são adicionados e os existentes mudam o tempo 
todo, levando a novos recursos sendo criados em bancos de dados 
constantemente. É muito difícil garantir que as políticas certas 
estejam sempre em vigor.
• Fundamentalmente, uma política de controle de acesso 
implementada apenas com os controles nativos de um banco 
de dados deve tomar suas decisões com base em informações 
estáticas (principalmente a identidade do usuário e o tipo de 
recurso que está sendo acessado). Isso é insuficiente no mundo 
atual de nuvem de dados, onde apenas o mecanismo interno de 
segurança da empresa não pode mais proteger os seus recursos 
(afinal, os dados estão distribuídos e são acessíveis via web). Nesse 
cenário, credenciais de usuário roubadas ou comprometidas 
podem levar à perda massiva de dados.
57
1.3.2 Controle de Acesso Baseado em Atributos (ABAC)
De acordo com os princípios de zero trust (confiança zero), o Controle 
de Acesso Baseado em Atributos (ABAC) usa vários atributos dinâmicos 
para tomar decisões de política (DAS,2018).
Esses atributos não precisam ser limitados à identidade/ função do 
usuário e aos nomes dos recursos do banco de dados. Também podem 
incluir alguns ou todos os seguintes atributos (KUHN, 2010):
• Grupos organizacionais do usuário, unidade organizacional e 
outros dados do usuário.
• Endereço IP e a localização geográfica de origem da solicitação.
• Atributos do dispositivo solicitante (por exemplo, se o dispositivo 
é emitido pela empresa ou de propriedade do usuário e qual é a 
postura de segurança do dispositivo atual).
• Sensibilidade (determinada dinamicamente) dos dados acessados 
(por exemplo, dados que se assemelham a endereços de e-mail, 
números de telefone ou números de cartão de crédito seriam 
considerados altamente confidenciais).
• Comportamento anterior do usuário.
Observe que a maioria dos atributos listados acima vão além das 
informações disponíveis no próprio banco de dados. Especificamente, 
essa abordagem requer que a camada de acesso a dados use 
autenticação federada para se integrar à arquitetura maior de 
gerenciamento de usuários e dispositivos da organização, em vez de 
depender apenas das informações que residem no banco de dados.
A autenticação federada se refere ao método de vincular a identidade 
de um usuário em vários sistemas separados de gerenciamento de 
58
identidade. Permite que os usuários mudem rapidamente entre os 
sistemas, mantendo a segurança.
Embora seja difícil de implementar, o controle de acesso baseado 
em atributos pode potencialmente abordar casos de uso e desafios 
de segurança que não podem ser resolvidos usando a abordagem 
tradicional baseada em RBAC. Aqui, estão alguns exemplos de políticas 
baseadas em atributos (KUHN, 2010):
• As informações de identificação pessoal de funcionários só podem 
ser acessadas por funcionários do departamento de RH usando 
dispositivos corporativos.
• Os usuários que pertencem ao grupo chamado analistas podem 
acessar todos os dados em modo somente leitura, mas com dados 
confidenciais impedidos de serem redigidos ou escritos.
• A reautenticação com um fator adicional deve ser acionada 
quando é feita uma tentativa de acessar dados altamente 
confidenciais específicos.
• Uma tentativa de infiltração lenta deve ser sinalizada se um 
usuário for visto acessando continuamente dados confidenciais 
(que está autorizado a acessar), em pequenos pedaços durante um 
período de tempo.
As abordagens tradicionais, como RBAC, para controle de acesso, 
são insuficientes para proteger dados em nuvem, pois o número e a 
variedade de bancos de dados em uso pela organização aumentam 
rapidamente e a maioria dos novos bancos de dados é hospedada 
na nuvem, e as equipes de segurança precisam aplicar políticas 
consistentemente nos bancos de dados locais e na nuvem.
Usando o controle de acesso baseado em atributos, as equipes podem 
aplicar políticas de acesso uniformemente em vários armazenamentos 
59
de dados e minimizar os riscos associados a credenciais compartilhadas, 
credenciais roubadas e ataques internos.
Por fim, podemos dizer que, apesar de todo esse controle, existem 
ameaças que focam justamente nesse tipo de serviço. Eentre alguns 
exemplos, segundo Goodrich (2013), pode-se citar:
• Acesso físico: caso um agente ameaçador tenha acesso físico, esse 
tipo de controle será inútil, pois sepode-se copiar tais informações.
• Interceptação por observação: uma senha pode estar anotada em 
um papel, que pode estar à vista de qualquer pessoa em uma sala 
de servidor.
• Contornando a segurança: pode-se esperar acesso somente via 
web, mas pode tentar acessá-lo por outra forma.
• Explorando hardware/ software: pode-se instalar pequenos 
hardwares na rede (raspberry) ou algum programa de espionagem, 
como um cavalo de Tróia.
• Descarte (incorreto) de mídia: pode-se recuperar dados apagados 
de mídias descartadas de forma incorreta. Existem casos em que a 
empresa descarta (literalmente joga no lixo) incorretamente seus 
servidores. Desse modo, se alguém tiver acesso a este hardware, 
poderá recuperar os dados e obtê-los.
• Interceptação eletrônica: pode-se incluir grampos em cabos de 
rede, tendo, assim, as mesmas informações do indivíduo clonadas.
• Acessando redes: muitas organizações criam conectores de rede 
além do esperado, logo, alguma pessoa não autorizada pode 
plugar sua máquina nesses conectores para ter acesso a rede.
60
1.3.3 Cenários comparativos de aplicação de RBAC e ABAC
A seguir, são apresentados alguns exemplos com o objetivo de ajudá-lo 
a entender quando é melhor utilizar RBAC e quando os sistemas ABAC 
podem funcionar melhor (DAS, 2018).
• Pequenos grupos de trabalho: RBAC é a melhor opção. Definir o 
trabalho por função é simples quando a empresa é pequena e 
os arquivos são poucos. Por exemplo, se você trabalha em uma 
empresa com apenas quinze funcionários, um sistema RBAC será 
mais eficiente e fácil de configurar.
• Grupos de trabalho geograficamente distribuídos: ABAC é a melhor 
escolha.