Banco de dados III - UVA

Prévia do material em texto

BANCO DE DADOS III
BANCO DE DADOS III
Copyright © UVA 2020
Nenhuma parte desta publicação pode ser reproduzida por qualquer 
meio sem a prévia autorização desta instituição.
Texto de acordo com as normas do Novo Acordo Ortográfico 
da Língua Portuguesa.
AUTORIA DO CONTEÚDO
Marla Miranda Loiola Dore Carvalho
REVISÃO
Janaina Vieira
Lydianna Lima
PROJETO GRÁFICO
UVA
DIAGRAMAÇÃO
UVA
SUMÁRIO
Apresentação
Autor
6
7
Implementação de Banco de Dados 32
• Projeto Físico de Banco de Dados
• Criando Esquemas de Banco de Dados
• Criando Instâncias de Banco de Dados
UNIDADE 2
8
• Administração de Banco de Dados
• Projeto de Banco de Dados
• Mapeamento do Diagrama de Classes
Gerência de Banco de Dados
UNIDADE 1
SUMÁRIO
Controle de Transações com SQL-DTL 62
• Instrução Commit
• Instrução Rollback
• Instrução Savepoint
UNIDADE 4
48
• Importância do Controle e Segurança do Banco de Dados com SQL-DCL
• Instrução Grant
• Instrução Revoke
Gerenciamento do Controle e Segurança de Dados
UNIDADE 3
6
A disciplina Banco de Dados III tem como ementa a administração de banco de dados. 
Por meio desse estudo veremos a parte conceitual e os serviços necessários relaciona-
dos às ferramentas para gerenciar e monitorar um banco de dados focando a segurança 
dos serviços. A disciplina engloba também o desenvolvimento de projeto de banco de 
dados, abarcando o de vida de um projeto e as habilidades e competências necessárias 
para a administração de um banco de dados visando à maior segurança e adequação a 
infraestruturas díspares. O mapeamento do modelo relacional é outro tópico importante 
desta unidade, que também apresenta quais são as expertises de um analista de siste-
mas que lhe permitam compreender melhor as necessidades do cliente e projetá-las, 
respeitando as regras que envolvem entidades e relacionamentos. O tópico sobre a im-
plementação de banco de dados também englobará o desenvolvimento na linguagem 
SQL (Structured Query Language). Serão destacadas as estruturas da linguagem, que 
são: SQL-DCL (Data Control Language), que trata de comandos com o objetivo de viabili-
zar o controle e a segurança de banco de dados, e SQL-DTL (Data Transaction Language), 
composta por comandos para controle e gerenciamento de transações.
APRESENTAÇÃO
7
MARLA MIRANDA LOIOLA DORE CARVALHO
Bacharelado em Informática pela Universidade Católica do Salvador – UCSAL. Especia-
lização em Sistemas Distribuídos Universidade Federal da Bahia – UFBA e mestrado em 
Tecnologias para Educação Universidade do Estado da Bahia – UNEB. Atua com de-
senvolvimento de software desde 2002 e, desde 2004, tem se especializado em data 
science, machine learning e ERPs, atuando como desenvolvedora, analista de sistemas, 
gerente de TI, consultora de TI e professora nas modalidades presencial e a distância. 
Professora e pesquisadora do Centro Universitário Jorge Amado – Unijorge, fomentando 
startups de tecnologia, educação e saúde, responsabilidade social, automação, inteligên-
cia artificial, games, processamento de imagens e auditoria de dados. Consultora em 
data science e inovação de TI. Palestrante em eventos para desenvolvedores de software 
como Database Day, SQLDay e DevFestNE.
AUTOR
Gerência de Banco de Dados
UNIDADE 1
9
Administrar um banco de dados — BD é, de forma resumida, instalar, configurar, monito-
rar e gerenciar problemas de um Sistema Gerenciador de Banco de Dados — SGBD . Com 
base nessas tarefas, a serem desenvolvidas na administração de um BD, um administra-
dor de banco de dados tem as seguintes responsabilidades:
• Definir regras de segurança.
• Tomar decisões de como os dados são representados na base de dados armazenada.
• Mapear o projeto físico da base de dados.
• Definir procedimentos de recuperação.
• Monitorar o desempenho do servidor de BD por meio de ferramentas.
• Acompanhar a análise de desempenho de consultas, detecção de anomalias, aná-
lise de bloqueio e deadlock.
• Fornecer suporte à análise de requisitos dos usuários relativos a demandas de 
acesso a dados.
• Gerenciar mudanças nas estruturas dos bancos de dados para atendimento das 
alterações dos requisitos.
De um administrador de BD também é esperado o conhecimento das regras de negócios 
dos demais sistemas, a fim de que haja integração de dados, respeitando a segurança 
de cada sistema.
INTRODUÇÃO
Nesta unidade você será capaz de:
• Compreender a administração de banco de dados e o processo de implementa-
ção a partir do modelo relacional de banco de dados.
OBJETIVO
10
Administração de Banco de Dados
Para administrar um BD você pode utilizar mais de uma ferramenta — inclusive, não 
precisa que elas estejam na mesma plataforma (mesmo sistema operacional ou 
mesmo tipo de rede).
Cada fornecedor da ferramenta adotada tem um book com a documentação de suas 
ferramentas. No entanto, é necessário sempre acompanhar os lançamentos das versões 
e a compatibilidade de cada ferramenta com a versão em uso.
SQL Server 2019 
Considere que estejamos tratando do SQL Server 2019. A seção de docs da Microsoft 
tem uma visão geral de cada ferramenta.
As versões chamadas Express podem ser baixadas para testes, uma vez que 
não são exigidas licenças para utilização, pois o foco são o aprendizado e a 
disseminação das ferramentas. Obviamente, há um interesse da empresa 
para que o uso da ferramenta seja ensinado em faculdades e universidades, 
pois dali podem surgir novos empresários, dos quais é esperado que, por já 
as conhecerem , deem preferência a essas ferramentas. 
Independentemente da troca de interesses ou não, faça sua escolha de acor-
do com as necessidades de seu cliente, considerando as verbas disponíveis.
No site da Microsoft existe o link para baixar a versão gratuita do SQL Server 2019 
Express. Nessa versão, você pode aplicar o conhecimento que estamos construindo 
nesta disciplina.
Baixe, instale, verifique os requisitos de sua máquina e coloque a mão 
na massa!
11
Existem, inclusive, comunidades nas quais grande parte dos membros são voluntários 
que mantêm essas documentações. Há, no entanto, setores dos próprios fornecedores 
destinados a manter contato direto e contínuo com várias dessas comunidades. Vale a 
pena pesquisar. Cada estado, em cada país, tem pelo menos uma comunidade em cada 
capital com foco em disseminar conhecimento.
Outra ferramenta bastante útil e que possibilita trabalhar técnicas para otimiza-
ção de banco de dados, gerando grande melhoria na performance dos BD, é o 
DETA (Database Engine Tuning Advisor). O DETA Tem por objetivo realizar uma 
análise de como as consultas são processadas no banco de dados e, assim, é 
capaz de fazer recomendações para otimizar o desempenho dessa consultas 
por meio de modificações nas estruturas do banco de dados, tais como a cria-
ção de índices, views (consultas) indexadas e particionamentos.
Exemplo
Certificação MVP 
No caso da Microsoft, há, inclusive, certificações, sendo uma delas a MVP – Microsoft 
Most Valuable Professional em SQL, mediante a qual são reconhecidos especialistas 
técnicos de comunidades do mundo inteiro que, voluntariamente, dividem seus conheci-
mentos sobre tecnologias da Microsoft e, em contrapartida, recebem benefícios de via-
gens e suporte para serem o que é chamado evangelista da tecnologia na qual desejam 
se especializar.
Na rede social Twitter existem vários evangelistas a serem seguidos, cujo con-
teúdo promove altas discussões, em nível técnico e colaborativo.
Que tal procurar evangelistas das ferramentas que você utiliza e colaborar para 
sua melhoria contínua?
Siga o @SQLServer ou o @oracledobrasil. Siga também o evangelista @Crespi-
DB, palestrante que dá altas dicas sobre BD.
Ampliando o foco
12
Linhas de comando 
Você pode administrar um banco de dados por meio de linhas de comando. Um bom 
administrador tem na manga vários comandos que são mais usuais, mas que também 
podem ser críticos. Logo, é necessário saber o momento certo de utilizar, pois problemas 
podem ser ocasionados.Use com moderação! 
Um exemplo de comando é o SHRINKDATABASE.
O SHRINKDATABASE reduz os arquivos de data e log, sendo aplicado a todos os arqui-
vos do banco de dados (.mdf, .ndf ou .ldf) em um só momento. Importante ressaltar que 
esses arquivos são de duas categorias (dados e log). Convencionou-se que:
• O primeiro arquivo de dados terá a extensão .mdf – Master Data File.
• Os demais arquivos de dados terão a extensão ndf. – Secondary Data File.
No entanto, se rodarmos o comando quando um backup estiver agendado ou em pa-
ralelo na base de produção associado a outras ferramentas, alguns dados podem ser 
interrompidos, podendo impactar também o tratamento de transações.
A indicação é utilizar juntamente com a análise do monitoramento do 
servidor de BD. 
Vamos ver um exemplo?
Na empresa Analize, um administrador de banco de dados está envolvido na aquisição e no 
desenvolvimento de novos sistemas, sendo requisitado para analisar possíveis integrações 
de sistemas, debatendo as necessidades de novos perfis de acesso de usuários, camadas 
de comunicação e formas de transferência de dados de um sistema para o outro.
Substituirei os nomes dos sistemas por nomes fictícios para representar melhor uma 
situação real para você.
Imagine um sistema financeiro que gerencie mensalidades e serviços de alunos em uma 
instituição de ensino. Esse sistema, que chamaremos de Academy, deve integrar-se com 
o sistema já desenvolvido por uma empresa de cobrança, o Charge.
13
Nesta situação, o administrador de banco de dados, também chamado admin, deve 
destacar regras de acesso a dados e campos-chave de integração dos registros dos 
movimentos financeiros do sistema que receberá os dados financiados, o Academy, ali-
nhado com o nível de detalhe de informações que os gestores da empresa e usuários 
experientes que acessam os dados — os chamados stakeholders — consideram impor-
tantes no momento de uso.
Campos-chave Admin
São as chaves primárias de cada 
entidade.
Termo que faz alusão ao usuário admin 
padrão nos SGBDs.
No entanto, o admin deve destacar outros sistemas que também necessitarão daqueles 
dados, como:
• Um setor chamado Controladoria que possui um sistema, o Controller.
• Outro setor chamado Contabilidade, o Account, que contabiliza e audita todos os 
dados de entrada e de saída.
Nesse contexto, importante ressaltar a importância do admin:
• Destacando a integração dos sistemas que se refletem na redução de trabalho 
por meio da comunicação entre os setores e a segurança de dados.
• Analisando os perfis de segurança.
• Monitorando o processamento das consultas dos bancos de dados de cada sistema. 
• Destacando os requisitos mínimos para atendimento ao processamento dos da-
dos que demandam consumo da banda de dados da rede da empresa, assim como 
comunicação e troca de dados com links entre suas filiais e possíveis servidores de 
replicação de dados. 
• Assegurando a qualidade no tempo de resposta necessário para a execução 
dos serviços.
14
Projeto de Banco de Dados
Agora que já conhecemos a importância da administração de um banco de dados, vamos 
aprender como criar os projetos de BD.
Um projeto faz parte do que chamamos de ciclo de vida do projeto, sendo dividido em 
três fases ou níveis principais:
I. Modelo conceitual.
II. Modelo lógico. 
III. Modelo físico. 
Modelo conceitual 
Na primeira fase, o modelo conceitual ou MCD (modelo de alto nível) envolve a represen-
tação do mundo real. Para que essa ilustração ocorra acontece a etapa de análise de 
requisitos ou levantamento de necessidades e regras — em que é coletada dos usuá-
rios a forma como os processos ocorrem para que possa ser definido como deverão ser 
agrupados e interligados em um banco de dados.
Nesta fase não há interferência da tecnologia da ferramenta a ser adotada para 
gerenciar os dados.
Importante
Modelo lógico
Na segunda fase, o modelo lógico ou MLD consiste na especificação lógica dos dados 
em um formato adequado ao SGBD que será utilizado. Ou seja, apesar de ainda não 
estar atrelado à ferramenta nessa fase, é necessário especificar o tipo de cada campo 
pertencente à entidade. No entanto, os tipos disponíveis estão vinculados à ferramenta 
que será usada. Sabe-se que existem tipos comuns a todas as ferramentas, chamados 
de tipos primitivos. Contudo, cada ferramenta, seja ela SQL Server ou Oracle, MySql, tem 
suas especificações, dependendo inclusive da versão que está em uso. Dessa forma, ao 
representar os tipos nos campos em cada entidade, é necessário atentar-se aos detalhes 
na especificação de alguns tipos, representando esses campos e entidades por meio de 
um diagrama chamado Diagrama de Entidade-Relacionamento, ou DER.
15
Existem tipos específicos para armazenar letras ou caracteres, que podem ser 
os tipos var e varchar. Contudo, se for utilizar a ferramenta Oracle, também 
existem tipos exclusivos para essa ferramenta, como o tipo varchar2, disponí-
vel desde o Oracle 8 e que difere na forma como armazena seus dados, como 
bytes ou caracteres.
Exemplo
Modelo físico
Na terceira fase o modelo físico ou MFD (modelo de baixo nível) será definido a partir 
do modelo lógico, detalhando os componentes, como tabelas, campos, tipos de valores, 
restrições e relacionamentos.
O livro Projeto de Banco de Dados, de Heuser — indicado nas referências e dis-
ponível na Biblioteca Virtual — trata de todas as fases e conceitos pertinentes 
ao desenvolvimento de um projeto de BD. 
Ampliando o foco
Modelo Entidade-Relacionamento — ER 
Os conceitos centrais da abordagem do modelo ER indicado na segunda fase do projeto 
de BD são:
• Entidades: tabelas ou objetos de armazenamentos de dados.
• Relacionamentos: formas de comunicação entre as entidades sobre as quais se 
mantém uma conexão e que estão relacionadas com as cardinalidades das rela-
ções entre as entidades.
• Atributos: campos que compõem as entidades, com seus tipos e restrições es-
pecíficos.
16
Conceito Símbolo
Entidade
(1,1)
Relacionamento
(1,1)
Atributo
(1,1)
Atributo identificador
(1,1)Relacionamento 
identificador
(1,1)
Generalização/
especialização
(1,1)
Entidade associativa
(1,1)
Figura 1: Símbolos usados na representação de um esquema ER.
Fonte: Heuser (2011, p. 62.).
17
Cada entidade deve ter um identificador que corresponde ao conjunto de propriedades 
(atributos e relacionamentos) cujos valores servem para distinguir diferentes registros.
A cardinalidade de uma entidade em um relacionamento, de acordo com Heuser (2011), 
corresponde ao número de ocorrências de uma entidade que pode estar associada a 
uma determinada ocorrência de entidade por meio do relacionamento.
Há dois tipos de cardinalidade: a cardinalidade máxima e a cardinalidade mínima. 
Outros conceitos importantes são:
• Generalização/especialização
Representam uma entidade intitulada pai ou mãe, que contém atributos genéricos. 
Já as entidades relacionadas à entidade pai ou mãe contêm atributos específicos. 
O que as diferencia é o sentido da ligação entre elas.
Conforme Heuser (2011), o conceito de generalização/especialização permite atri-
buir propriedades particulares a um subconjunto das ocorrências especializadas 
de uma entidade genérica.
• Entidade associativa
Entidade criada para representar uma cardinalidade de muitos para muitos.
A entidade Pessoa está relacionada à entidade PessoaJurídica.
A relação de Pessoa para PessoaJurídica é de especialização.
A relação de PessoaJurídica para Pessoa é de generalização.
Exemplo
Muitos para muitos
Termo utilizado na multiplicidade de uma relação matemática, em que existem 
várias formas de relações nos dois sentidos.
Ampliando o foco
18
Um aluno pode cursar muitas disciplinas, assim como uma disciplina pode ser cur-
sada por muitos alunos. Esse tipo de relação é denominada “muitos para muitos”.
Exemplo
Vamos entender melhor esses conceitos? 
Observe a figura a seguir:
Analisando a imagem podemos perceber que:
• A entidade Filial tem relação com a entidade Cliente.• A entidade Cliente tem uma relação do tipo especialização com as entidades 
PessoaFísica e PessoaJurídica.
Observe, na imagem, o símbolo que representa a especialização, destacando que:
• Na entidade Cliente, temos os atributos comuns, que são código e nome.
• Nas entidades especializadas, temos os atributos característicos de cada uma — 
na entidade PessoaFísica, os atributos CPF e sexo, e, na entidade PessoaJurídica, 
os atributos CNPJ e tipo de organização.
Figura 2: Representação gráfica de um caso ER.
Fonte: Adaptada pelo autor (2020).
FILIAL CLIENTE
(1,1) (0,n)
nome
codigo
PESSOA
FÍSICA
PESSOA
JURÍDICA
CPF sexo CNPJ tipo deorganização
19
Repare que, no atributo código da entidade, Cliente tem um círculo preenchido. Isso 
quer dizer que o campo não pode se repetir mais de uma vez no preenchimento dessa 
entidade — o que convencionamos chamar de chaves primárias.
Com referência à cardinalidade, representada na Figura 2, podemos interpretar algumas 
situações.
Situação 1 
Existe uma filial fictícia chamada MDC que já foi criada, mas ainda não tem clientes.
Cada filial tem que se relacionar com seus clientes. No entanto, no dia em que foi lança-
da, a referida filial ainda não tinha nenhum cliente. Assim, representa-se a necessidade 
de existir:
• 1 (um) registro na entidade Filial.
• 0 (zero) registros na entidade Cliente.
Situação 2 
A filial MDC foi criada e já tem vários clientes cadastrados na entidade Cliente. Esses 
vários clientes são representados pela letra “n” na cardinalidade (0,n).
Exemplos de uso de entidades e relacionamentos podem ser verificados no 
Capítulo 2, item 2.3, do livro Projeto de Banco de Dados, de Heuser. Além 
disso, no item 2.8 existem exercícios que ajudarão a sanar dúvidas e rever os 
conceitos deste tópico. 
Ampliando o foco
Retomemos agora o conceito de modelo lógico.
O MLD representa um nível de abstração que independe da ferramenta de SGBD que 
será utilizada. Independentemente do fato de ser Oracle, SqlServer ou qualquer outra, o 
modelo lógico se manterá.
Vamos ver como isso funciona na prática? 
20
Observe, a seguir, um Diagrama de Entidade-Relacionamento — DER em que a entidade 
Produto, que tem como chave primária o atributo código, tem um relacionamento com 
a entidade Tipo de Produto.
PRODUTO TIPO DEPRODUTO
n 1
preço
código descrição código descrição
Figura 3: Diagrama de Entidade-Relacionamento.
Fonte: Heuser (2011).
Agora, vamos representar esse mesmo relacionamento em um modelo lógico no qual o nível 
de abstração do usuário passa a depender do SGBD que ele está utilizando. Assim, a Figura 
3 será representada no modelo físico com seus dados preenchidos pela Figura 4, a seguir.
Figura 4: Representação da entidade com dados preenchidos.
Fonte: Heuser (2011).
Figura 5: Modelo lógico do exemplo
Fonte: Heuser (2011).
A Figura 5 representa o modelo lógico a ser implementado no modelo físico.
21
Assim, a união de uma modelagem conceitual, de um modelo lógico e de 
um modelo físico, gera um projeto de banco de dados.
Sistema Gerador de Banco de Dados – SGBD 
Os SGBDs oferecem técnicas que garantem que certos usuários ou grupos de usuários 
somente acessem determinadas entidades ou partes de um BD.
Para tanto, é necessário garantir a definição de restrições apropriadas, assim como o 
monitoramento das interações dos usuários para garantir que as restrições não estejam 
sendo violadas pelo sistema. Alguns dos privilégios que podem ser concedidos são: AL-
TER, DELETE, EXECUTE, INDEX, INSERT, REFERENCES, SELECT, UPDATE.
A respeito dos comandos da linguagem DCL, podemos destacar as sintaxes GRANT 
e REVOKE. 
A sintaxe do comando GRANT concede o privilégio de indicar o acesso à permissão da 
operação que será dado a cada objeto por um usuário ou grupo de usuários:
A sintaxe do comando REVOKE tem o objetivo de remover privilégios concedidos 
anteriormente:
No entanto, para a implementação do projeto físico é necessário especificar os 
tipos inerentes a cada ferramenta.
Importante
GRANT Privilégio(s) ON Objeto TO Usuário(s) [WITH GRANT OPTION]
REVOKE [GRANT OPTION FOR] Privilégio(s) ON Objeto 
 FROM Usuário(s) {RESTRICT | CASCADE}
22
Transação 
Uma transação é o conjunto de comandos a serem processados respeitando-se a in-
tegridade e a consistência de dados. Esse processamento pode ser todo executado, ou 
não, garantindo a atomicidade das informações.
A sintaxe básica de uma transação é:
BEGIN TRANSACTION 
--Corpo de comando 
COMMIT ou ROLLBACK
No Capítulo 15 do livro SQL: Structured Query Language, de Damas, disponível 
em Minha Biblioteca, são abordados os comandos de SQL-DCL e de Data Con-
trol Language que tratam de comandos com o objetivo de viabilizar o controle 
e a segurança de banco de dados, entre os quais podemos destacar os coman-
dos GRANT, REVOKE E DENY. Nos Capítulos 14 e 16, são tratados os coman-
dos de SQL-DTL e de Data Transaction Language, compostos por comandos 
para controle e gerenciamento de transações envolvendo BEGIN TRANSAC-
TION, COMMIT E ROLLBACK.
Ampliando o foco
23
Mapeamento do Diagrama de Classes
Ao fazermos um DER, estamos representando um mundo no modelo chamado relacional.
Outro paradigma de representação é o Modelo Orientado a Objetos — OO.
Um dos componentes da orientação a objetos chama-se Diagrama de Classes, no qual 
são representadas entidades. No entanto, essas entidades terão seus comportamentos 
indicados por métodos integrados a cada uma.
Assim, o mapeamento conceitual será representado pelo Diagrama de Classes, seguindo 
a representação da Linguagem de Modelagem Unificada — UML.
Os conceitos de entidades e seus atributos são correspondentes aos conceitos no mode-
lo relacional, sendo no modelo OO chamados de classes e atributos da classe. 
As relações que envolvem entidades, em que essas entidades eram chamadas de fracas 
— uma não existe sem a outra —, são denominadas composição. 
A herança que representa a generalização/especialização também é representada por 
um triângulo e continua existindo a representação da quantidade de relações entre uma 
classe e outra, também chamada de cardinalidade.
Modelo Orientado a Objetos
O mapeamento de orientação a objetos pode ser considerado uma extensão do modelo 
relacional, no qual são inseridas características de orientação a objetos.
As técnicas de modelagem orientada a objeto utilizam a Linguagem de Modelagem Uni-
ficada (do inglês, UML – Unified Modeling Language) e, por meio da UML, representam 
nove diagramas. Um deles é o Diagrama de Classes, que tem relação com os conceitos 
da abordagem ER (entidade-relacionamento).
A mudança de paradigma de um modelo ER para um modelo de objetos chega como 
uma forma diferente daquela a que estávamos habituados. No entanto, a utilização de 
bancos de dados relacionais ainda é uma prática comum na maioria das empresas.
24
Bancos de dados relacionais rodando no que chamamos de back end e 
sistemas modelados a OO são uma forma de trabalho pertencente aos 
modelos de desenvolvimento de softwares. 
Há, no entanto, outros conceitos que representam os tipos ou modificadores de acesso 
de cada atributo e métodos da classe, sendo eles público, protegido ou privado, em que 
os símbolos de cada um, respectivamente, são, +, # e -.
Os modificadores de acesso se diferenciam pela forma como cada item pode 
ser acessado somente na classe ou por outras classes .
Importante
O Capítulo 12 do livro Banco de Dados - Projeto e Implementação apresenta 
exemplos e descreve um paralelo de cada tipo de Modelo Entidade-Relaciona-
mento — MER para o Diagrama de Classes.
Ampliando o foco
Para trazer mais exemplos e agregar mais valor ao seu conhecimento, recomendamos 
que você consulte exercícios resolvidos, tente refazê-los e, principalmente, pratique o de-
senvolvimento da análise. Para isso, atenção às dicas:
I. Foque a interpretação do texto.
II. Identifique quais objetos representam o mundo real.
III. Esses objetos são atributos ou classes? Diferencie, questionandose o item é uma 
característica de algo ou um objeto que tem outros detalhes e comportamentos.
IV. Entre essas classes, verifique se há características específicas que podem ser 
objetos diferentes do mundo real e se há características comuns. Definido isso, 
teremos classes-pai e classes-filhas.
Lembra da Pessoa e PessoaJurídica? A Pessoa seria a classe-pai e Pessoa-
Jurídica, assim como PessoaFísica, seria a classe-filha, que herda atributos e 
métodos da classe Pessoa.
Exemplo
25
V. Após definir quais são as classes e os atributos, tente relacioná-los e represente 
a quantidade de sua existência, o quantitativo que pode haver em cada objeto 
relacionado ao outro, indicando, assim, sua cardinalidade.
Quanto mais exercícios fizer, mais você trabalhará as habilidades neces-
sárias para entender o comportamento de cada sistema, as necessida-
des de evoluções, suas alterações futuras e poderá discutir melhor com 
um cliente que deseje implementar soluções. 
Camada de persistência 
Na Análise Orientada a Objetos — OO, podemos introduzir alguns conceitos, entre eles, a 
camada de persistência. 
De acordo com Machado (2001), a camada de persistência é uma biblioteca que permite a 
realização do processo de persistência, isto é, o armazenamento e a manutenção do esta-
do de objetos em algum meio não volátil, como um banco de dados, de forma transparente.
Essa camada de persistência tem o objetivo de isolar os objetos do sistema de mudan-
ças do mecanismo de armazenamento. Ou seja, por meio desses mecanismos, diminui o 
acoplamento entre os objetos e a camada do sistema, possibilitando que este seja mais 
flexível e portátil. No entanto, há a desvantagem da sobrecarga dessa intermediação.
Diagrama de Classes 
A linguagem UML é uma linguagem de modelagem visual, composta por diagramas 
que representam estruturas que compreendem os componentes estáticos do sistema 
como um todo, por meio de representações estáticas e representações comporta-
mentais que disponibilizam informações do comportamento do sistema, ou seja, re-
presentações dinâmicas. 
Assim, destacamos o Diagrama de Classes como um diagrama que representa a es-
trutura de um sistema.
Sobre a Análise Orientada a Objetos — OO, no que se refere ao desenvolvimento de um 
Diagrama de Classes, a ideia central é concentrar a construção do sistema em torno 
dos objetos (mais próximo do mundo real).
26
No Diagrama de Classes o analista precisa:
• Identificar essas entidades em um conjunto de objetos.
• Uma entidade irá representar um conjunto de objetos que tenham determinadas 
características em comum.
• Identificar como esses objetos interagem entre si. Essa interação pode ser por:
• Requisição de um serviço.
• Reação a uma outra mensagem.
Uma classe é representada conforme a Figura 6, a seguir, em que:
• Os atributos são informações da entidade/classe.
• Os métodos são ações que podem ser realizadas pelos objetos.
Classe
+atributo1 
+atributo2 
+atributo3
+Metodo1() 
+Metodo2()
Nome da classe
Atributos da classe
Métodos da classe
Figura 6: Diagrama de Classes.
Fonte: Elaborada pela autora (2020).
Leia o Capítulo 12 do livro Banco de Dados – Projeto e Implementação, disponível 
em Minha Biblioteca, em que são resumidas regras de implementação de projetos.
Ampliando o foco
27
Assim, finalizamos a Unidade 1. Esperamos que tenha sido esclarecedora e que você 
possa praticar e compreender a importância de entender um contexto e a necessidade 
de um cliente, passando pelas fases de construção de um projeto de BD e representando 
os comportamentos realizados no mundo real por meio de diagramas que recebem da-
dos e comunicam-se mediante trocas de mensagens que são instanciadas.
Para ampliar seu conhecimento veja o material complementar da Unidade 1, 
disponível na midiateca.
MIDIATECA
28
Qual é, então, a ferramenta que podemos usar para monitorar os serviços no 
SQL Server?
A ferramenta SQL Profiler monitora todas as transações executadas no banco 
de dados, todos os traces ou vestígios. Por meio dessa ferramenta é possível 
identificar consultas que estão demandando mais recursos da máquina, poden-
do-se sugerir divisão de querys ou refatoramento de um código (termo aplicado 
a fim de otimizar um procedimento), assim como verificar melhores horários de 
utilização de consumo da rede a fim de sugerir agendamento de backups.
O que é importante focar ao utilizar uma ferramenta de monitoramento de dados?
Podemos realizar o monitoramento em um servidor que chamamos de produ-
ção, ou seja, que está sendo utilizado pelos usuário no momento da manipula-
ção das ferramentas ou em um servidor de testes, em que podemos descartar 
outras variáveis que possam influenciar o ambiente. Podemos, ainda, realizar 
procedimentos que não impactem dados reais.
Dessa forma, quando ainda não identificamos o trace, colocamos para rodar 
a ferramenta SQL Profiler, que monitora cada ação que é executada no SQL 
Server, seja um login, a execução de um query, o bloqueio de uma variável, um 
procedimento ou uma instrução Transact-SQL. Seja proveniente do Manage-
ment Studio ou da aplicação, um vestígio é deixado no banco de dados com 
todas as informações sobre aquele procedimento que está sendo executado. 
Imaginemos uma situação real...
O usuário André tem acesso ao sistema financeiro Charge e realizou, ao longo 
do dia, várias baixas de mensalidades e serviços com seu usuário. No entanto, 
ao fim do dia, identificou uma divergência entre o relatório do caixa recebido 
e os valores de entrada. André emitiu um relatório detalhado dos pagamen-
tos efetuados com seu usuário naquele dia. Para sua surpresa, não localizou o 
comprovante de pagamento de Edgar Codd, que constava como baixa em seu 
relatório do dia.
NA PRÁTICA
29
Dessa forma, ele abriu um chamado para o setor de TI solicitando verificação 
do procedimento daquela baixa de Edgar Codd e informou o horário em que 
começou a trabalhar naquele dia. O chamado aberto para a TI foi encaminhado 
para o setor que administra o servidor de BD, onde está o database do sistema 
Charge, que analisa a tabela em que registra os dados financeiros. No entanto, 
o comentário do horário do usuário chamou a atenção do administrador de BD, 
que analisou também outros dados referentes ao processamento da procedure 
de pagamento que estão armazenados. Por tratar-se de uma execução que 
consideramos como funcionalidade principal do sistema ou funcionalidade crí-
tica, foram armazenados dados para possíveis auditorias, como IP da máquina, 
username, nome do computador, entre outros.
Dessa forma, as informações de horário de execução de baixa do cliente indicado 
“Edgar Codd” e o nome de computador indicaram que outro usuário teve acesso 
ao usuário e senha do funcionário André, pois não era a máquina que o funcioná-
rio sempre usava. Foi aberto, então, um procedimento administrativo para cruzar 
dados da filmagem daquele dia de uma câmera de segurança que havia no local, 
para verificação de pessoas que estavam no setor no momento da baixa.
O administrador de BD gerou um relatório relatando o fato, notificando setores 
que estariam envolvidos: o setor de Recursos Humanos, que tomou providên-
cias; e o próprio setor de TI, sugerindo mudanças como permissão de horário 
de acesso à rede de acordo com o horário do funcionário. Apontou também a 
necessidade de viabilizar uma forma de comunicação entre as gerências dos 
setores e o setor de TI para possíveis alterações com prévia comunicação. Noti-
ficou o acontecido ao núcleo de desenvolvimento do sistema Charge, relatando 
o fato e sugerindo que também constassem no relatório analítico de pagamen-
to do caixa dados como hora exata da baixa e máquina utilizada. Foi sugeri-
da também adição de token (dispositivo de segurança adicional) ao acessar o 
login do sistema para que cada usuário tivesse acesso a ele. O administrador 
notificou também o setor de gerenciamento das câmeras, solicitando o registro 
da informação de manutenção dos aparelhos paraa necessidade de cruza-
mento de dados.
30
Resumo da Unidade 1
Na disciplina sobre a administração de banco de dados, apresentamos conceitos impor-
tantes sobre segurança, monitoramento de traces e gerenciamento dos serviços em um 
banco de dados, enfatizando a atenção às competências de um analista de sistemas, 
que englobam o conhecimento de administração de um banco de dados, passando pelo 
levantamento de requisitos e o desenvolvimento de um modelo conceitual e lógico de um 
projeto de BD a ser implementado. Por fim, tratamos da abordagem de outro paradigma 
de análise, que é a orientação a objetos, a qual caminha em paralelo à utilização de ban-
cos de dados relacionais, demonstrando que uma análise relacional pode ser comple-
mentada por meio de um Diagrama de Classes presente em uma análise OO.
Conceito de representação do mundo real, especificamente a abstração, pen-
sando em cada camada separadamente, focando o monitoramento e a per-
formance de um SGBD, a robustez da decisão de aplicação de uma tecnologia 
associada às condições de um ambiente que favoreça melhor absorção de 
seus recursos e a representação dos comportamentos de cada instância de 
um objeto representado.
CONCEITO
31
Referências 
DAMAS, L. SQL – Structured Query Language. Rio de Janeiro: LTC. Minha Biblioteca.
HEUSER, C. A. Projeto de Banco de Dados. 6. ed. Porto Alegre: Bookman, 2011. Minha 
Biblioteca.
MACHADO, F. N. R. Banco de Dados: projeto e implementação. São Paulo: Saraiva, 2009. 
Minha Biblioteca.
Implementação de Banco de Dados
UNIDADE 2
33
Esta unidade aborda a análise e a implementação de projetos físicos de Banco de Da-
dos — BD, tratando regras de normalização e sintaxe de scripts, possibilitando que sejam 
aplicados os conceitos e a interpretação inerentes a um analista de sistemas focado em 
administração de BD, assim como aplicação de ferramentas para o auxílio na automati-
zação de processos.
INTRODUÇÃO
Nesta unidade você será capaz de:
• Realizar a implementação de banco de dados a partir do Diagrama de Classes.
OBJETIVO
34
Projeto Físico de Banco de Dados
O projeto físico de banco de dados deve ser realizado após ter sido feito o projeto lógico. 
A evolução de um projeto para o outro envolve outros fatores que vão além de simplesmen-
te iniciar a codificação na linguagem SQL (Structured Query Language, ou Linguagem de 
Consulta Estruturada). 
O principal motivo para que seja feita uma análise ao se iniciar o projeto físico é o custo 
elevado da manutenção dos sistemas, especialmente com os esquemas dos BDs, além 
do impacto negativo na confiabilidade perante o cliente no desenvolvimento de projetos 
pela empresa responsável.
Ao iniciar-se o projeto físico de BD, devem ser considerados e analisados os seguintes 
aspectos:
• Respeitar as regras de normalização de BD.
• Analisar o volume de dados que serão armazenados.
• Avaliar a disponibilidade do serviço de BD para atender ao processamento do sis-
tema que o acessará.
• Identificar entidades críticas do sistema, a fim de garantir alta performance no 
processamento das transações.
• Seguir padronização na declaração de nomes de tabelas, campos e transações, a 
fim de facilitar a codificação na linguagem SQL.
• Considerar a integração com outras bases de dados, destacando a compatibili-
dade dos tipos de dados, principalmente dos atributos-chaves (campos que serão 
relacionados a outras tabelas).
• Considerar a capacidade de recuperação de dados.
Regras de normalização 
As regras de normalização de BD consistem na forma como os dados são organizados 
em tabelas e como devem se relacionar, havendo uma fundamentação de álgebra rela-
cional que justifica o respeito a essas regras.
Analise bem antes de tomar a decisão de repetir os dados em um BD. 
35
Vamos ver um exemplo?
Imagine uma empresa XPTO que necessite de um banco de dados em cada filial por 
questões de segurança — para que cada uma não fique sem conexão que possibilite a 
replicação e sincronização das bases de dados. Para tanto, uma análise bem crítica às 
exceções de situações que necessitam de redundância de dados é indicada, como si-
tuações de replicação de dados em empresas que têm mais de um servidor de BD para 
atender filiais diferentes da XPTO.
Conforme pode ser visto na Tabela 1, uma das regras de normalização chama a atenção 
para a não repetição de dados, em se percebe que o valor do dado no campo cidade irá 
se repetir. Logo, há a necessidade explícita de criação de uma tabela chamada Cidade, 
bem como a criação do relacionamento da tabela Aluno com a nova tabela Cidade.
Aluno Cidade
João Alberto Rio de Janeiro
Maria Alda Salvador
Joana Silva Salvador
Alberto Cunha Rio de Janeiro
Tabela 1: Exemplo de tabela Aluno não normalizada.
Fonte: Elaborada pela autora (2020).
É necessário manter a documentação sempre atualizada com novas solicita-
ções ou alterações de regras de negócio que envolvam mudanças no esquema 
do BD. Para tanto, é importante que a equipe de desenvolvimento tenha a docu-
mentação do BD como parte da metodologia de desenvolvimento de sistemas 
da empresa em que você atua.
Importante
36
Tabelas críticas
As tabelas críticas podem gerar mais gargalos no sistema, ou seja, são tabelas que têm gran-
des números de inserção de registro, acesso por uma quantidade grande de usuários, regras 
de negócios que exijam recursos da máquina e possam impactar no processamento do BD.
Portanto, quanto ao item das tabelas críticas a serem analisadas, devemos considerar as 
seguintes orientações:
• Definir os índices a serem criados.
• Identificar tabelas com grandes volumes de dados para eventual particionamento.
• Identificar hierarquias de generalização/especialização (entidades-pai e entidades 
que possuirão tipos herdados).
• Descrever domínios discretos para eventual implementação de constraints.
• Decidir se a integridade referencial será garantida pelo SGBD ou por aplicação.
• Definir parâmetros para garantir a disponibilidade dos dados conforme requisitos.
Importante também analisar as principais consultas para considerar:
• Os índices a serem criados nas tabelas — otimizar as consultas é um ponto-chave.
• O número de usuários que acessam ao mesmo tempo, chamados usuários con-
correntes estimados.
• A performance na execução da transação.
Implementação de banco de dados com SQL 
Para realizar a implementação do BD na linguagem SQL após análise e observação de 
integração e demais itens descritos, é necessário entender a sintaxe para execução de 
cada um dos comandos para criação, alteração e deleção do esquema de BD:
• Resolvendo os trabalhos propostos e desafiando-se a aplicar os comandos da 
linguagem SQ.
• Fazendo análises de projeção de BD em contextos diferentes, seja com exercícios 
já resolvidos ou se organizando e separando um tempo para praticar, analisar e ima-
ginar situações de crescimento de um banco de dados.
• Analisando a quantidade de usuários acessando ao mesmo tempo ou um sistema 
web acessando esse BD, que, dessa forma, tem a necessidade de tempo de resposta 
com processamento de transação que impeça o sistema de ter perda de dados ou de 
não conseguir executar transações com o tempo mínimo de conexão disponível. 
37
São grandes desafios, não é verdade? 
Porém, ao colocarmos esses sistemas em produção, essas situações ocorrerão, e um 
bom analista de sistemas deve considerar todos esses itens para que a performance seja 
cada vez mais eficaz.
O livro SQL: Structured Query Language (Damas), disponível na Biblioteca Vir-
tual, disponibiliza exercícios e exemplos sobre a aplicação de todos os coman-
dos necessários para a implementação de um BD.
Ampliando o foco
38
Criando Esquemas de Banco de Dados
Os esquemas, ou schemas, são uma coleção de objetos, que podem ser tabelas, con-
sultas, índices, transações, procedures, dentro de um determinado database (banco de 
dados), com o objetivo de organizar e agrupar esses elementos de forma a centralizar 
a estrutura e os dados de um BD em umlocal que possa ser monitorado e gerenciado.
Fazendo uma relação com um arquivo 
com pastas e documentos físicos, o ar-
quivo em si seria o esquema ou database. 
No entanto, esse arquivo teria regras para 
armazenar somente dados de serviços 
específicos ou setores de uma empresa.
Na figura 1, é representado o esquema 
do database BD_TECNOLOGIA.
Observe que, dentro do database, é organi-
zado em pacotes ou subpastas cada grupo 
de elementos que compõem o database, 
como diagramas, tabelas, views, agenda-
mentos de backups, acesso de usuários, 
entre outros.
Figura 1: Esquema do database BD_TECNOLOGIA.
Fonte: Elaborada pela autora (2020).
A forma como o esquema foi criado, com suas tabelas e regras, impacta direta-
mente a performance e a segurança do BD.
Importante
A propriedade, ou pertencimento, dos objetos de esquemas pode ser transferida entre 
seus donos ou usuários. Essa mudança pode ser realizada por meio do comando ALTER 
AUTHORIZATION.
Os objetos podem ser movidos entre esquemas. Essa mudança pode ser realizada por 
meio do comando ALTER SCHEMA.
39
O gerenciamento de acesso de usuário pode ser feito via grupos, o que facilita o geren-
ciamento de permissões, e um único esquema pode conter objetos pertencentes a vários 
usuários do BD.
Permissões em esquemas e em objetos contidos pelo esquema podem ser concedidas. 
Esse acesso pode ser realizado por meio do comando GRANT.
Construção do esquema do BD 
Vamos conhecer algumas dicas valiosas para a construção do esquema do BD?
1. Escolha o tipo de dado mais adequado.
A escolha do tipo pensado em integração com demais sistemas, assim como a 
definição de tipos objetivando a utilização de menor ocupação de espaço no ser-
vidor, seja este na nuvem ou não, é muito importante.
2. Utilize os recursos do SGBD
Os SGBDs, sejam SQL Server, Oracle, MySQL, têm ferramentas nativas que cola-
boram com o monitoramento e o melhor funcionamento do BD quanto a aspectos 
de performance, de segurança e de regras.
Um campo como a sigla de um estado que só ocupa dois caracteres não tem 
por que não delimitar o tamanho do campo a dois.
Exemplo
Se um campo aceita valores somente F ou M, para Feminino ou Masculino, uti-
lize sempre check constraint, opção para adicionar restrições a cada campo a 
fim de validar os valores. Se o campo tem um valor-padrão a ser iniciado, utilize 
a opção default. Atitudes simples como essa podem evitar inconsistência de 
dados e que o usuário consiga injetar dados não esperados no BD.
Exemplo
40
3. Analise esporadicamente os índices.
Os índices se refletem no desempenho de suas consultas, procedures e triggers 
em seu BD. A forma como o usuário mais utiliza a busca também pode influenciar 
o percentual do tempo de resposta.
4. Evite SELECT *
Os BDs são conjuntos. Então, por que não aplicar as uniões e as interseções que 
eles possibilitam sempre? Cada SELECT * executado em seu BD gastará recurso 
desnecessário de sua infraestrutura, assim como enviará uma grande quantidade 
de dados que consumirão banda da sua rede de dados.
Em uma tela de pesquisa de um sistema XPTO, os usuários utilizam bastante a 
opção de adicionar o caractere % que, quando associado ao comando LIKE, per-
mite buscas sem a necessidade de se conhecerem dados exatos, como o nome 
completo do aluno, possibilitando informar o primeiro nome adicionado ao ca-
ractere % e o último sobrenome — assim são consultados os registros na BD. 
Exemplo
Mesmo que você vá realizar testes, evite fazer consultas sem condições, princi-
palmente em horários críticos, a não ser que o objetivo seja testar a performan-
ce do servidor por meio de técnicas de stress, que aumentam a demanda de 
solicitações, dados e processamento da máquina.
Exemplo
41
5. Avalie os planos de execução de consulta.
Ferramentas como o SQL Query Analizer, ainda em uso, fornecem o plano de oti-
mização de consultas após ativação da opção.
Tenha marcos de análise de performance de cada schema de seu SGBD — se 
possível, em um servidor chamado “Testes”, no qual não haja interferência dos 
usuários e que lhe permita comparar o processamento de rotinas mais críticas 
de um sistema específico, possibilitando-lhe descartar outras variáveis que po-
deriam interferir na otimização das consultas.
Exemplo
42
Criando Instâncias de Banco de Dados
Um administrador de BD deve conhecer a infraestrutura necessária para gerenciar melhor 
e monitorar o processamento de seus serviços. Isso engloba conhecimentos de hardware, 
software e de comunicação nos diversos tipos de redes em que os dados sejam comutados. 
Esses conhecimentos devem envolver também as rotinas de backups e testes neces-
sários para a necessidade de utilização das cópias de segurança, assim como estabe-
lecimento ou alinhamento de procedimentos que envolvam a utilização dos recursos de 
SGBD e a melhor performance para execução das suas solicitações.
Antes de inicializar o SGDB, ou seja, criar instâncias, verifique se os requisitos da máquina 
são atendidos, conforme descrição na Tabela 2. Para a versão Express do SQL Server, 
também são descritos os requisitos mínimos.
Componente Requisito
Disco rígido
Mínimo de 6 GB de espaço disponível no disco rígido, podendo va-
riar a depender da versão e das ferramentas adicionais instaladas.
Recomendamos instalar o SQL Server em computadores com 
os formatos de arquivo NTFS ou ReFS. O sistema de arquivos 
FAT32 tem suporte, mas não é recomendado, pois é menos se-
guro do que os sistemas de arquivos NTFS ou ReFS.
Unidades somente leitura mapeadas ou compactadas são blo-
queadas durante a instalação.
Memória
• Mínimo: 
Edições Express: 512 MB. 
Todas as outras edições: 1 GB.
• Recomendado: 
Edições Express: 1 GB.
Todas as outras edições: pelo menos 4 GB e deve ser aumen-
tado à medida que o tamanho do banco de dados aumenta 
para garantir um ótimo desempenho.
Tabela 2: Requisitos para Instância de um SGBD.
43
Velocidade do 
processador
Mínimo: processador x64: 1,4 GHz. 
Recomendado: 2,0 GHz ou mais rápido.
Tipo do processador
Processador x64: AMD Opteron, AMD Athlon 64, Intel Xeon com 
suporte Intel EM64T, Intel Pentium IV com suporte EM64T.
Fonte: Adaptada de Mídia 7 (2020).
Por falta de conhecimento de algumas personalizações que podem beneficiar o proces-
samento do SGBD, a instalação acaba seguindo as opções-padrão. 
Uma instância do SQL Server pode ser interpretada como um contêiner em que coloca-
mos nossos dados. As configurações podem impactar a forma de resposta de interação 
do SQL Server com o hardware — como espaço em disco e gerenciamento de memória.
Uma boa forma de economizar espaço é optar pela otimização do processo de backup, 
configurando de maneira personalizada a realização do agendamento dos backups, com 
momentos de gravação do arquivo de Log, por exemplo.
Quando tratamos de BD, você deve pensar em formas e ferramentas para ge-
renciar todos os componentes que são instanciados junto com ele. 
Importante
Uma das funções do administrador de BD também é fazer a manutenção dos índices. 
Existe o recurso de manutenção, ou maintenance plans, que faz tratamentos gerais dos 
databases criados em um SGBD. No entanto, para casos específicos, a criação de scripts 
pode auxiliar melhor o monitoramento. 
A vantagem de se utilizar os planos de manutenção é que eles podem 
fazer uma determinada tarefa em vários bancos de dados.
44
Indicamos a criação do script rebuid de todos os índices existentes em todos os 
bancos de dados da instância SQL Server.
Ampliando o foco
Uma dica: a ferramenta SSMS (SQL Server Management Studio) é utilizada 
para conectar-se à instância do SQL Server e executar comandos T-SQL (Tran-
sact-SQL) para monitorar os objetos de cada database.
Ampliando o foco
45
Para ampliar seu conhecimento veja o material complementar da Unidade 1, 
disponível na midiateca.
MIDIATECA
Na empresa Audity há a necessidade de se manter o histórico sintetizado dos 
valores recebidos no dia anterior na base de dados de cada filialpara que seja 
feita uma checagem ao iniciar o processo de conferência de valores recebidos 
e de valores por forma de recebimento conforme extratos bancários. Esse pro-
cedimento demandava um tempo grande e custo de horas dos funcionários.
Foram, então, criados scripts que processavam durante noite e, pela manhã, 
eram emitidos relatórios que semiautomatizavam os trabalhos dos conferen-
cistas que auditavam os valores em cada filial.
A análise e o comportamento de requisitos para o BD podem gerar diferentes 
possibilidades de melhorias na performance, desde:
• Aplicação de otimização de consultas.
• Reagendamento de horários de backups.
• Criação de índices.
• Compactação de bancos de registros de acesso a dados (Logs).
• Duplicação gerenciável de dados.
• Upgrade na infraestrutura.
Entre outras opções que o monitoramento e a análise do feedback dos usuários 
podem gerar, o analista deve estar atento ao tempo de resposta dos serviços e 
às necessidades dos clientes nos mais variados níveis, seja operacional, geren-
cial ou executivo, proporcionando otimização de dados de forma resumida ou 
detalhada, ou seja, com nível de granularidade ou detalhes distintos.
NA PRÁTICA
46
Resumo da Unidade 2
Nesta unidade nós nos aprofundamos mais sobre criação, monitoramento, modelagem 
de BD e implementação de bancos na linguagem SQL. Atentamos para a melhoria con-
tínua dos códigos, assim como para o monitoramento necessário para melhores per-
formance e utilização dos recursos de hardware e de software necessários para o de-
sempenho do BD instanciado. As dicas e mídias referenciadas são muito importantes 
para descrição e visualização de utilização de ferramentas e desenvolvimento de scripts. 
Então, vamos lá! Aproveitem todas as informações e desenvolvam.
O conceito de instância também é tratado na orientação a objetos, na lingua-
gem UML, em que a palavra “abstrair” refere-se a armazenar todos os compo-
nentes de um BD em um contêiner, monitorando as solicitações e os acessos 
para melhorar o desempenho.
CONCEITO
47
Referências 
DAMAS, L. SQL – Structured Query Language. Rio de Janeiro: LTC, 2007. ISBN Digital: 
9788521632450. Minha Biblioteca.
HEUSER, C. A. Projeto de Banco de Dados. 6. ed. Porto Alegre: Bookman, 2011. ISBN 
Digital: 9788577804528. Minha Biblioteca.
MACHADO, F. N. R. Banco de Dados: projeto e implementação. São Paulo: Saraiva, 2009. 
ISBN Digital: 9788536518978. Minha Biblioteca.
Gerenciamento do Controle e 
Segurança de Dados
UNIDADE 3
49
Uma palavra que define bem os cuidados com gerenciamento do controle e segurança 
de dados é organização. Esta unidade contempla o tratamento e a implementação da 
linguagem SQL a partir dos comandos DCL, que lhe permitirão gerenciar um BD, tratan-
do aspectos fundamentais do controle de acesso, monitoramento e auditoria de dados 
alinhados à política de segurança adotada.
INTRODUÇÃO
Nesta unidade você será capaz de:
• Realizar o controle e a segurança de banco de dados.
OBJETIVO
50
Importância do Controle e Segurança do 
Banco de Dados com SQL-DCL
O papel do administrador de Banco de Dados também está relacionado a segurança e 
auditoria dos dados alinhadas às regras de negócio da empresa, de forma que os itens de 
segurança estejam alinhados com o Plano Diretor de Tecnologia de Informação – PDTI 
da instituição. O plano detalha segurança de dados e segurança de redes, definindo pa-
drões de procedimentos de gestão, tanto da Tecnologia da Informação – TI, quanto dos 
procedimentos adotados pela empresa.
Falar sobre Segurança de Dados nos leva a um assunto cada vez mais debatido, que é 
a Lei Geral de Proteção de Dados – LGPD. Tal lei estimula a utilização mais segura dos 
dados, tanto pelo cliente que os fornece, quanto pela instituição, que pode compartilhar e 
utilizar estes dados para outros fins. Por exemplo, a empresa utilizar o cadastro de cliente 
para repassá-lo para empresas fazerem divulgação de produtos e serviços.
Dados capturados das redes sociais podem, a partir de análise de perfis de 
usuários, beneficiar tanto estratégias de marketing quanto investimento em bol-
sas de valores e até mesmo decisões e impactos na política e economia.
Exemplo
Uma dica: leia sobre os impactos e cuidados que cada pessoa, independente-
mente da especialidade de TI, deve seguir com relação aos dados que com-
partilha, pensando de forma crítica o que essa captura de dados pode gerar ou 
influenciar, a depender da análise que é feita a partir deles.
Ampliando o foco
51
Pilares da segurança da informação 
Tratando-se de segurança de dados é importante enfatizar os quatro pilares da seguran-
ça da informação:
Confidencialidade
É o modo de garantir que a informação estará acessível apenas 
para pessoas autorizadas.
Integridade
Refere-se ao objetivo de assegurar que a informação esteja pro-
tegida contra qualquer alteração. Ao se tratar de alterações são 
englobados os camandos de update, de insert e delete dos re-
gistros no BD assegurando-se que os dados estejam íntegros, 
conforme as últimas operações realizadas , sejam de alteração, 
inclusão ou exclusão.
Disponibilidade
Os dados precisam estar seguros e disponíveis para serem 
acessados próximo a 100% de quantidade de solicitações. Ser-
viços necessários para que o BD esteja disponível atendo-se à 
sua arquitetura: se é um BD distribuído ou BD na nuvem, que to-
dos os requisitos estejam funcionando para que atendam aos 
usuários autorizados desejando serviços de qualidade e que 
estejam sempre “no ar”, ou seja, em funcionamento com estru-
turas necessárias para que isso venha a acontecer.
Autenticidade
Objetiva garantir que os dados sejam autênticos, que possibili-
tem os registros de alterações dos dados.
Portanto, as informações devem ser mantidas somente para o acesso de usuários au-
torizados, assim como implementar ações que protejam os dados contra vazamentos, 
ataques ou danos em geral.
Medidas de controle 
Para proteger um BD contra problemas de segurança e garantir que esses objetivos se-
jam alcançados é fundamental implementar três medidas de controle, que são: controle 
de acesso, controle de fluxo e criptografia.
52
Controle de Acesso
Em um sistema de BD multiusuário o sistema deve oferecer técnicas para permitir o ge-
renciamento de bloqueio de registro e de acesso dos usuários a um conjunto que tenha 
acesso somente à parte selecionada dos dados, sem que tenham acesso ao restante 
do banco. Assim, isso é fundamental ao tratar-se de um grande banco de dados inte-
grado que precisa ser acessado por vários usuários e sistemas dentro da instituição.
Logo, o SGBD inclui um sistema de autorização de acesso e um subsistema de seguran-
ça que são responsáveis por garantir a segurança do banco de dados contra acesso não 
autorizado. São usados dois mecanismos para isso:
• Mecanismos de Segurança Discricionários - São usados para conceder acesso 
aos usuários para consulta e atualização aos arquivos, registros (ou tuplas) e cam-
pos de um BD.
• Mecanismos de Segurança obrigatórios – Esses recursos são utilizados para ge-
renciar usuários ou grupo de usuários de acordo com seus perfis ou papéis (roles).
 
Controle de Fluxo
Essa medida de controle acontece de forma similar a aparelhos de rede que têm ge-
renciamento de rota, em que os dados somente são enviados para os endereços ou 
destinatários que têm acesso a eles. Assim, limitam a possibilidade de usuários que não 
possuem permissão acessarem os dados que estão trafegando.
Criptografia
Essa medida possibilita aumentar a segurança de dados utilizando algoritmos de emba-
ralhamento de dados em que somente o usuário com permissão conseguirá acessá-los 
na ordem que deveria ser mostrada e de acordo como foi enviada.
ISO 27001
A gestão da Segurança da Informação da estrutura pode ser elaborada de acordo com 
a norma ISO 27001. A adequação dos procedimentos para atender à norma englobam 
questões operacionais que possibilitem o monitoramento das informações, não espe-
cificando quais ferramentasdevem ser adotadas, mas sugerindo boas práticas. Estas 
requerem desde a aquisição de equipamentos de redes que façam o melhor controle do 
53
fluxo, quanto o desenvolvimento de procedimentos automatizados que armazenem o 
histórico dos dados e sua alteração.
No esquema a seguir são destacadas as etapas da ISO 27001, em que a organização é o 
foco principal, sendo necessário passar pelos ciclos de planejamento, operacionalização, 
verificação e somente depois a implementação, que faz parte da ISMS – Information 
Security Management System.
PLAN
Estabelecer o ISMS.
ISO 27001
ACT
Implementar 
e operar 
o ISMS.
DO
Implementar 
e operar 
o ISMS.
CHECK
Monitorar e revisar o 
ISMS.
Figura 1: Etapas da ISO 27001.
54
Instrução Grant 
A linguagem SQL (Structured Query Language) é aplicada a bancos de dados conside-
rados relacionais, com entidades, relacionamentos e diagramas. Destaca-se que os co-
mandos SQL são divididos em:
• DDL (Data Definition Language) ou Linguagem de definição de dados.
• DML (Data Manipulation Language) ou Linguagem de manipulação de dados.
• DQL (Data Query Language) ou Linguagem de recuperação de dados.
• DCL (Data Control Language) ou Linguagem de controle de dados.
Dentre os grupos de comandos citados, as instruções DCL alteram as permissões no 
banco de dados, sendo usadas para controle de acesso e gerenciamento dos usuários 
nos bancos de dados. Podem permitir ou negar ações para usuários nas tabelas ou re-
gistros, sendo que o controle por registros é chamado de segurança de nível de linha.
Sobre os comandos:
SQL GRANT é um comando utilizado para fornecer acesso ou privilégios sobre os obje-
tos de banco de dados para os usuários.
GRANT -> Atribui privilégios de acesso do usuário a objetos do banco de dados.
Ao codificar comandos na linguagem SQL é uma boa prática utilizar caixa alta 
para as palavras reservadas da linguagem e caixa baixa para utilização de de-
mais itens como campos e tipos. 
GRANT privilege_name
ON object_name
TO {user_name |PUBLIC |role_name}
[WITH GRANT OPTION];
Exemplo
55
Tratando os privilégios
Os privilégios ou controle de acessos podem ser concedidos aos comandos que cada 
grupo de usuário ou usuário terá ao database (banco de dados de cada sistema), tabela 
ou componente do BD. A seguir destacamos:
SELECT – Permissão para ler todas as tabelas ou consultas especificadas, continuando 
as permissões mesmo após alterações na estrutura da tabela.
INSERT – Permissão de inserir linhas na tabela especificada ou campo específico de 
uma tabela.
DELETE – Permissão de apagar linhas ou tuplas da tabela especificada.
REFERENCES – Permissão de definir chaves estrangeiras.
WITH GRANT OPTION – Permite que o usuário possa repassar a permissão a outros 
usuários. 
Se o objeto criado for uma visão, o usuário que a criou terá sobre ela os mesmos privilé-
gios que tem sobre as visões e tabelas utilizadas na visão. Para criar uma visão é neces-
sário ter, no mínimo, privilégio de seleção em todos os objetos utilizados.
Destaco que apenas o dono de um schema (ou Diagrama de Entidade Relacio-
namento - DER) pode executar CREATE, ALTER e DROP. Esse tipo de privilégio 
não pode ser repassado ou revogado.
Privilégios são concedidos havendo sempre a necessidade de identificação do 
usuário e senha antes da execução de comandos. 
Importante
Para o administrador de BD definir os papéis dos usuários os seguintes itens devem ser 
levados em consideração:
• Grupo de operação ou privilégios.
• Grupo de objetos a que o papel terá acesso.
• Grupo de usuários ou papéis que farão parte desse papel específico.
56
Instrução Revoke
A segurança de banco de dados é implementada para resolver questões:
• Legais e éticas quanto ao acesso e manipulação dos dados.
• Políticas que possibilitem a confidencialidade das informações em diversos níveis.
• De funcionamento do SGBD referente à infraestrutura de hardware e de software 
para que a disponibilidade seja atendida.
• Da hierarquização de acesso aos dados com a necessidade de gerenciamento de 
perfis de usuário e controle de acesso deste ao SGBD.
O comando REVOKE, também pertencente ao grupo DCL (Data Control Language) ou 
Linguagem de controle de dados, remove direitos de acesso do usuário ou privilégios 
para os objetos de banco de dados.
Assim, a sintaxe do comando é demonstrada, sendo que o REVOKE tem por finalidade 
remover os privilégios de acesso aos objetos obtidos com o comando GRANT.
REVOKE privilege_name
ON object_name
FROM {user_name |PUBLIC |role_name}
REVOKE é o comando complementar ao comando GRANT. Com ele pode tanto ser re-
tirada uma permissão de acesso ou o GRANT OPTION de um privilégio de um usuário 
específico. A sintaxe só mesmo:
REVOKE [GRANT OPTION FOR] privilégio ON objeto FROM usuários {RESTRICT 
CASCADE} 
A cláusula RESTRICT faz com que a cláusula a ser executada trate exceções de usuários 
específicos no momento da retirada de acessos a objetos de BD.
57
Removendo permissões. 
Desejo retirar a permissão de seleção do usuário joao no database academico, 
ou seja, o * representa todas as tabelas do database academico.
REVOKE SELECT on academico.* from joao
Outro exemplo: em vez de retirar a permissão apenas de uma tabela específica, 
não se utiliza o * e indica-se o nome da tabela após o database.
REVOKE SELECT on academico.aluno from joao
Exemplo
Auditoria de banco de dados 
A auditoria em banco de dados auxilia a identificar possíveis alterações não permitidas 
em registros que podem impactar em demais regras de negócio do sistema que faz uso 
do SGDB.
Dessa forma, para que se efetive a auditoria alguns itens são necessários, como:
• Ações que devam ser auditadas.
• Disponibilização de relatórios ou ferramentas de BI (Business Intelligence) para 
analisar as operações.
• Cruzar dados que identifiquem atividades suspeitas.
Tratando-se de Banco de Dados, a auditoria relaciona-se ao processo de identificação e a 
proteção dos dados contra pessoas que não são autorizadas. A partir da análise realiza-
da na auditoria de dados é possível examinar os logs gerados pelo Sistema Gerenciador 
de Banco de Dados (SGBD). Com esses logs pode-se localizar usuários que estão reali-
zando alguma operação ilegal, como visualizando dados que ele não está autorizado a 
visualizar.
58
O Administrador de Banco de Dados (DBA) geralmente é a pessoa responsável por efe-
tuar a auditoria, realizando o diagnóstico de problemas de execução do Sistema Geren-
ciador de Banco de Dados e o monitoramento das operações realizadas pelos usuários 
do sistema. O administrador confronta dados a partir de aplicação da própria linguagem 
SQL para consultar as tabelas geradas no logs de acesso gerados para cada database, 
podendo diagnosticar alterações indevidas e eventuais exclusões nos dados do sistema. 
Para isso, o Sistema Gerenciador de Banco de Dados deve dispor de mecanismos que 
deem permissão para a realização dessas atividades conforme o nível de segurança.
Normas internacionais relacionadas ao processo:
ISO 12207 – Processo de Desenvolvimento de Software.
ISO 15408 – Segurança de Aplicação (desenvolvimento).
ISO 15504 – Processo de Desenvolvimento de Software.
ISO 27001 – Especificação de Sistema de Gestão de Segurança da Informação 
(2006).
ISO 27002 – Código de Prática para Gestão da Segurança da Informação.
As diretrizes destas instituições norteiam regras de funcionamento para aten-
der a três características: confiabilidade, integridade e disponibilidade.
Ampliando o foco
59
Para ampliar seu conhecimento veja o material complementar da Unidade 1, 
disponível na midiateca.
MIDIATECA
Ao administrar bancos de dados há a necessidade constante de criação de 
usuários. Logo, é muito mais prático gerenciar um grupo de usuários que pos-
suam as mesmas permissões. Assim, para criar o papel ou perfil, é necessário 
que o usuário possua o privilégio, podendo executar os comandos conforme o 
exemplo a seguir, considerando-se que se está trabalhando com um sistemaacadêmico e deseja-se dar permissões, regras, tabelas e comandos que pode-
rão acessá-las.
GRANT CREATE ROLE TO <usuario>
CREATE ROLE <nome do papel> [IDENTIFIED BY <senha>]
CREATE ROLE inclusao_de_notas
CREATE ROLE inclui_notas IDENTIFIED BY senhadificil
GRANT PRIVILEGIO(S) ON TABELAS(S) TO ROLENAME
GRANT SELECT, INSERT, DELETE, UPDATE on notas TO inclusao_de_notas
NA PRÁTICA
60
Resumo da Unidade 3
Esta unidade envolveu os principais itens referentes a segurança de dados, trazendo 
exemplos dos comandos GRANT e REVOKE, assim como reflexões a respeito da prote-
ção de dados e da necessidade e importância da execução de auditoria dos dados e dos 
acessos às base de dados.
O Capítulo 23 do livro Sistemas de Banco de Dados (Elsimari) trata a Segu-
rança e Autorização em Banco de Dados abordando as técnicas utilizadas 
para proteger o banco de dados, chamando a atenção e detalhando bem as 
questões de segurança, que envolvem desde questões éticas que referem-se 
ao comportamento dos usuários, assim como questões legais ao direito de 
acesso a certas informações. Lembrando que os pilares da tecnologia, hard-
ware, software e people, estão interligados à segurança e a todos os aspectos 
que esta pode vir a impactar.
CONCEITO
61
Referências 
DAMAS, L. SQL - Structured Query Language. Rio de Janeiro: LTC. ISBN Digital: 
9788521632450. Minha Biblioteca.
ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados. Rio de Janeiro: Pearson, 
2019 . Minha Biblioteca.
HEUSER, C. A. Projeto de Banco de Dados. 6. ed. Porto Alegre: Bookman, 2011. ISBN 
Digital: 9788577804528. Minha Biblioteca.
MACHADO, F. N. R. Banco de Dados: projeto e implementação. São Paulo: Saraiva, 2020. 
ISBN Digital: 9788536518978. Minha Biblioteca.
Controle de Transações 
com SQL-DTL
UNIDADE 4
63
Os comandos Data Transaction Language – DTL ou Linguagem de Transação de Dados 
são responsáveis por gerenciar diferentes transações ocorridas dentro de um Sistema 
Gerenciador de Banco de Dados – SGBD. Para que um conjunto de comandos possa ser 
gerenciado há propriedades que devem ser garantidas, recursos que devem ser controla-
dos e gerenciados para que mais usuários possam manipular os dados ao mesmo tem-
po e que a concorrência de acesso a esses dados atenda à qualidade e à confiabilidade 
do Banco de Dados – BD.
Neste sentido, esta unidade tem o objetivo de trabalhar os conceitos das transações 
realizadas em um BD, necessários para as competências de um administrador de BD, 
analista de sistemas ou profissional de TI para compreensão e aplicação dos conceitos 
e práticas que a área demanda. A gestão, controle e melhoria da eficiência de transações 
é um desafio de que trataremos nesta unidade, abordando para tanto as sintaxes, formas 
de aplicação, transações diferentes a depender da necessidade das diversas funcionali-
dades que um sistema demande.
INTRODUÇÃO
Nesta unidade você será capaz de:
• Realizar o controle de transações de banco de dados SQL-DTL.
OBJETIVO
64
Instrução Commit 
Transação é um processamento de tarefas que pode envolver vários dados e instruções 
de manipulação de registros em uma única execução. A transação é atômica, ou seja, 
deve ser considerada pelo SGBD como um componente único, em que todas as opera-
ções nela contidas sejam executadas no BD, ou nenhuma deve ser aplicada.
Todas as operações de uma transação devem ser executadas, ou nenhu-
ma será aplicada.
A sintaxe de uma transação pode envolver comandos de início e fim (BEGIN TRANSAC-
TION/END TRANSACTION), além de comandos de parada ou retorno à situação anterior 
à sua execução como um todo. No entanto, o padrão SQL-92 define que uma transação 
inicia-se a partir do comando SQL e engloba os comandos subsequentes até o fim da 
transação, com os comandos COMMIT ou ROLLBACK.
Propriedades da Transação
O SGBD deve garantir as quatro propriedades da transação, também conhecidas como 
ACID.
Imagine que você está em um caixa eletrônico consultando o saldo de sua con-
ta bancária. Considere este como o momento 1. Em seguida, você tenta sacar, 
o que já consideramos como momento 2. No entanto, houve falta de dinheiro 
no caixa eletrônico e a operação de saque não foi realizada. Neste instante o 
SGBD do sistema bancário volta o estado dos seus registros ao momento 1, 
permanecendo seus dados inalterados.
Exemplo
65
A
Atomicidade: o componente de recuperação de falhas do SGBD deve garantir 
que a transação é toda executada ou o estado anterior deve retornar. É a cha-
mada Lei do Tudo ou Nada. 
C
Consistência: os dados devem ser consistentes, estar de acordo as regras de 
negócio de seus atributos, chaves primárias, secundárias e demais compo-
nentes. Ou seja, se em um campo de uma tabela do SGBD existe uma regra 
de que aquele campo não deve ser nulo, a execução das transações deve 
atender a todas as regras de cada componente do database (banco de dados 
do sistema em questão).
I
Isolamento: cada transação deve ser tratada de forma isolada. O SGBD deve 
gerenciar a concorrência entre recursos a serem utilizados, utilizando, para 
tanto, um controle de concorrência (scheduler), que faz uso de bloqueio de 
registros que estão em uso, assim como recursos como memória e espaço 
em disco.
D Durabilidade: o SGBD deve garantir que, após a execução de transações, os dados permaneçam inalterados até o processamento de outra transação.
Estados da Transação
Uma transação pode ser executada com sucesso ou não. Quando não é executada com 
sucesso, as operações devem ser desfeitas por meio do comando ROLLBACK. Caso as 
instruções sejam executadas com sucesso, o comando COMMIT garante a atomicidade 
dos registros.
A figura a seguir representa os estados de uma transação, que são:
• Ativa: corresponde ao estado inicial e enquanto estiver sendo executada.
→ em efetivação: após todas as declarações da transação.
— commit (gravado): após o término da execução da transação.
→ em falha: após identificação de que a transação não poderá ser concluída 
normalmente.
— abort (abortado): após a transação ser desfeita e o BD retornar ao estado 
anterior.
66
Figura 1: Diagrama de Estado de Transação.
Fonte: Elaborada pela autora (2020).
Neste diagrama podemos identificar a mudança de estado durante o processamento de 
uma transação. Ao iniciar a transação com o comando BEGIN TRAN esta ficará no esta-
do Ativa e durante seu processamento poderá fazer operações de leitura e escrita no BD. 
Enquanto está processando fica no estado Em efetivação, ou seja, enquanto estiver em 
processamento pode ser abortada, retornando ao seu estado anterior à execução da 
transação a partir do comando ROLLBACK. Após executar o comando COMMIT, este 
gravará os dados no BD e dará a confirmação de que tudo foi gravado corretamente. 
Dessa forma, a transação vai para o estado finalizado com sucesso, estará no estado 
Gravado. Caso haja algum problema a transação ficará no estado Em Falha, executará o 
comando ROLLBACK e finalizará com o estado Abortado, finalizando a operação.
O SGBD gerencia os recursos e controla os acessos e liberações para estes. Neste senti-
do, é importante que o analista de BD entenda como funcionam pontos-chave envolvidos 
para o gerenciamento desses recursos, como segurança, bloqueios e desbloqueios, sin-
cronização entre as solicitações de vários usuários por meio das transações. Entenden-
do estes conceitos, a programação de scripts, a decisão por qual tipo de variável criar ou 
Os mecanismos de bloqueio em uma transação podem assegurar a integrida-
de física de cada transação e formas eficientes de controle delas. 
Ampliando o foco
Em
efetivação Gravado
Em
falha Abortado
Ativa
67
o modo de acesso a eles tenderá a ser mais adequado à eficiência e auxiliará na otimiza-
ção dos recursos existentes.
Quando várias transações são emitidas ao mesmo tempo (transações concorrentes), 
ocorre um escalonamento de operações destas. Algumas operações de uma transação 
são executadas; em seguida, seu processo é suspenso e algumas operaçõesde outra 
transação são executadas. O controle de estado das transações, utilizando algoritmos 
que controlem o estado de cada transação e da concorrência, gerenciando os recursos 
compartilhados entre as transações executadas em paralelo deve ser muito bem tratado. 
Depois que um processo é suspenso, ele é retomado a partir do ponto de interrupção, 
executado e interrompido novamente para a execução de outra transação. 
Modificações feitas por transações simultâneas devem ser isoladas das modificações 
feitas por qualquer outra transação simultânea. O isolamento deve garantir que duas 
transações, executadas de forma concorrente, tenham o mesmo resultado que teria se 
fossem executadas em ordem sequencial. 
Muitos problemas podem ocorrer quando transações sem controle de concor-
rência são executadas. Entre esses problemas encontramos:
• Perda de atualização.
• Atualização temporária (leitura suja).
• Agregação incorreta.
• Leitura não repetitiva.
Importante
Para conhecer mais sobre problemas de simultaneidade e de interfaces de 
conexão com o BD, pesquise sobre como o Sql Server trata algumas téc-
nicas, como: simultaneidade, leituras sujas, leituras de fantasma e leituras 
não repetíveis.
Ampliando o foco
68
Finalizada uma transação, seus resultados devem persistir, mesmo que ocorram falhas 
no SGBD, ou seja, as propriedades ACID devem ser garantidas. No dicionário, a palavra 
“persistir” significa: “demonstrar constância”, “insistência”; “perseverar”. Em tecnologia, 
especialmente em BD a persistência é um termo muito utilizado, pois há a necessidade 
da garantia de qualidade, de tentativas, de utilização de todos os recursos disponíveis até 
que sejam esgotadas todas as alternativas de qualidade e confiança dos dados proces-
sados e retornados.
Para saber mais detalhes sobre o processamento de procedimentos armazenados e 
compilados nativamente, pesquise sobre otimização de consultas, concorrência e deadlock. 
Você vai ver o quanto pode otimizar seu sistema e como isso pode beneficiar no processa-
mento das transações.
Ao codificarem-se scripts para transações, muitos recursos são demandados 
do servidor e da rede de dados, podendo fazer com que gargalos e problemas 
de tempo de processamento impactem na operacionalidade dos sistemas. 
Para melhor utilizar os recursos do servidor e do próprio cliente, sugiro fazer 
uso de ferramentas de otimização de código, assim como ferramentas de uso 
de recursos disponibilizadas pelo próprio SGBD e pelo Sistema operacional por 
meio do qual o servidor esteja sendo gerenciado.
Entender sobre ferramentas e gerenciamento de memória, assim como buscar 
dicas de melhoria da performance de um script podem fazem muita diferença, 
tanto no tempo de respostas do processamento das transações quanto na eco-
nomia de recursos e necessidade de upgrade da infraestrutura utilizada.
Sempre faça pesquisas para aprimorar seus conhecimentos!
Importante
Qual impacto se tem ao deixar scripts salvos no BD, como procedures e 
triggers?
Ampliando o foco
69
DTL
A DTL (Data Transaction Language ou Linguagem de Transação de Dados) é utilizada 
para gerenciar mudanças realizadas por instruções DML (Data Manipulation Langua-
ge ou Linguagem de Manipulação de Dados). Comandos como insert, update, seletc 
e delete fazem parte da manipulação de dados e serão utilizadas em conjunto no 
controle de transações. 
Como, então, aplicar a DTL?
O conceito de transação só se aplica aos comandos que fazem a manipulação de dados, 
DML, ou seja, comandos SELECT, INSERT, UPDATE e DELETE. Entende-se que qualquer 
interação com os dados pode ser considerada uma transação. No entanto, existem co-
mandos que podem controlar o momento de início, parada e interrupções planejadas. A 
seguir, um exemplo de sintaxe do código utilizando uma transação no SQL Server: 
Acesse e participe de fóruns de discussão. Eles agregam muito valor, pois é 
possível aprender com pessoas mais experientes. Existem vários, mas reco-
mendamos os oficiais da Microsoft, pois especialistas certificados nas tecnolo-
gias fazem contribuição de código e sugestão de melhoria sobre concorrência 
na seleção de dados.
Ampliando o foco
Sintaxe do BEGIN
BEGIN TRANSACTION 
 comando SQL(SELECT, INSERT,UPDATE,DELETE) 
IF @@ERROR <> 0 
 ROLLBACK 
ELSE 
 COMMIT 
Exemplo
70
Cabe acrescentar que, ao trabalharmos com BD, existe uma linguagem padrão chamada 
de SQL ANSI. Porém, existem ferramentas de fornecedores diferentes que, ao criarem 
seus SGBDs, tem a liberdade de fazer adaptações na linguagem considerada linguagem 
mãe das demais. Neste sentido, sintaxes diferentes são aplicadas aos demais BD, con-
forme a Tabela 1, como o próprio Sql Server, Oracle, Postgre, MySql, agora MariaDB, 
Informix e DB2. Destaco a seguir diferenças destas aplicações. No entanto, lembro que a 
lógica de aplicação segue a mesma linha de raciocínio. Acrescento que o uso de colche-
tes ([]) significa que o uso da cláusula é opcional.
Tabela 1: Sintaxe de Transações.
SGBD SINTAXE
SQL Server BEGIN [TRAN, TRANSACTION]
Oracle
BEGIN …
END;
Postgre BEGIN [WORK,TRANSACTION]
MySQL/MariaDB
BEGIN [NOT ATOMIC] ... 
END;
Informix BEGIN [WORK]
DB2
BEGIN ... 
END;
Fonte: Elaborada pela autora (2020). 
Para refletir
O que você faz quando depara-se com um termo técnico novo?
Quando surgir uma palavra nova aplicada, busque exemplos de sua utilização. 
Assim, você entenderá melhor a cada leitura e poderá aplicar a terminologia e o 
aprendizado. Uma sugestão é participar de palestras técnicas. Em um primeiro 
momento você irá deparar-se com muitos termos novos, mas a cada uma de 
que participar e pesquisar sobre as palavras que lhe chamaram a atenção, o 
seu vocabulário crescerá e seu conhecimento técnico também.
71
Instrução Rollback
O ROLLBACK é utilizado para desfazer as alterações realizadas. Ele é acionado caso haja 
algum erro na execução da transação ou no tratamento de exceção prevista, embutindo 
no script condições que façam voltar à situação inicial, liberando os recursos que a tran-
sação havia bloqueado para o seu processamento.
O ROLLBACK retorna para a configuração existente antes do erro de 
execução.
Quando uma transação altera o banco, é feita uma cópia dos dados anteriores à altera-
ção da instrução de ROLLBACK. Se uma outra transação estiver consultando os dados 
em paralelo à finalização da transação — que está tratando os mesmos dados antes da 
operação do COMMIT —, os dados que serão acessados são aqueles copiados antes da 
finalização do COMMIT dessa transação.
Neste sentido, imagine que duas pessoas estão acessando uma loja on-line. As duas 
possuem cartões da mesma conta corrente e limite único. No entanto, se uma transação 
não aguardar a outra ser executada e o limite do cartão não contemplar o valor das duas 
compras, a autorização da compra pode ser feita de forma a ultrapassar o valor do limite 
de compra para os dois cartões.
A sintaxe do ROLLBAK
ROLLBACK { TRAN | TRANSACTION }
 [ transaction_name | @tran_name_variable 
 |savepoint_name | @savepoint_variable ] 
[ ; ] 
Para saber mais detalhes de implementação e melhor aproveitamento do códi-
go em transações, pesquise sobre como o ROLLBACK é executado e o geren-
ciamento e liberação de recursos efetuado por ele, assim como mais detalhes 
sobre declaração de variáveis e tratamentos de erros.
Ampliando o foco
72
Utilização de Variáveis em transações
Como qualquer linguagem, a Transact-Sql possui palavras reservadas que não são indi-
cadas para serem declaradas como variáveis. A declaração de variáveis em uma tran-
sação é feita a partir da palavra reservada DECLARE, seguida do caracter @, o nome da 
variável e o tipo desta variável. Para comentários dentro de um script segue-se o padrão 
adotado em demais linguagens de programação: para uma linha adotam-se duas bar-
ras(//) e para comentários com mais de uma linha o /* */, conforme Sintaxe e exemplo 
de Atribuição de valor a seguir
-- Declaração da variável chamada var, emseguida informando o tipo da variável.
DECLARE @var data-type
-- Atribuição do valor entre aspas simples para a variável var.
SET @var=’valor’
-- Retornar valor da variável através do comando SELECT.
SELECT @var
No exemplo de Atribuição de valor é declarada a variável como nome Cliente do tipo var-
char(20), tamanho 20. A partir do comando SET é informado o valor recebido na variável 
e por meio do comando SELECT deve retornar o valor da variável na tela.
Uma variável local Transact-SQL é um objeto que pode conter um valor de dados de um 
tipo específico. As variáveis são aplicadas em situações como:
• Um contador, para ser utilizado no controle de vezes que uma transação deve ser 
executada, associado com estruturas de repetição.
Exemplo de Atribuição de valor:
DECLARE @Cliente varchar(20)
SET @Cliente=’Dore’
SELECT @Cliente
Exemplo
73
• Um totalizador, que também pode ser utilizado em transações associadas ou não 
a estruturas de repetição e de seleção.
• Como uma variável temporária, a fim de comparar dados do percorrer da transação.
• Para armazenar dados e utilizá-los como retorno de uma função, uma transação, 
stored procedure ou trigger.
Uma instrução DECLARE inicializa uma variável Transact-SQL por:
 
• Atribuir um tipo, um tamanho de uma variável passado pelo usuário ou por parâ-
metro de outra função.
• Atribuir um valor, devendo utilizar somente um @ para atribuição de valores, con-
forme Exemplo de Atribuição de valor.
• Definição de um valor como NULL.
Vale destacar que as formas de declaração de variação diferem de um SGBD para outro, 
seguindo a mesma lógica, no entanto pode haver alterações de sintaxe. Suas aplicações 
dependerão das situações que possam ser utilizadas na resolução de algum problema, o 
que pode implicar na forma de declaração de variáveis locais e globais na utilização em 
transações. Por exemplo, uma variável que terá a função de um contador somente da 
execução dentro de uma parte da transação, deve ser local e não global. 
Da interpretação da transação a seguir temos o seguinte:
A varável @nroAmb foi declarada como global em outro local por ser utilizada 
em mais de uma transação
Os nomes de algumas funções do sistema Transact-SQL começam com dois 
sinais de arroba (@@). Destaco que o uso de sua sintaxe segue as regras das 
funções.
Como avariável @@ERROR, utilizada para capturar erros retornados pelo SGBD.
BEGIN TRANSACTION T1
UPDATE Medicos SET nroa = NULL 
 WHERE nroa = @nroAmb 
Exemplo
74
Nível de Isolamento da transação
As transações especificam um nível de isolamento em que são definidos os modos de 
acesso aos recursos ou dados que possam ser compartilhados por outras transações. 
Os tipos de isolamento estão resumidos na Tabela 2, dividindo-os em quatro níveis, con-
forme definido pelo SQL-92.
Tabela 2: Níveis de isolamento da transação no SQL.
Nível de Isolamento Leitura suja(Dirty Read)
Leitura não repetível
(Nonrepeatable Read)
Fantasma
(Phantom Read)
Leitura não confirmada 
(Read uncommitted)
Sim Sim Sim
Leitura confirmada 
(Read committed)
Não Sim Sim
Leitura repetida
(Repeatable read)
Não Não Sim
Serializável
(Serializable)
Não Não Não
Fonte: Adaptado de docs.microsoft.com (2020).
IF @@ERROR <> 0 
 ROLLBACK TRANSACTION T1 
DELETE FROM Ambulatorios 
 WHERE nroa = @nroAmb 
IF @@ERROR <> 0 
 ROLLBACK TRANSACTION T1 
ELSE 
 COMMIT TRANSACTION T1 
….
75
Destaca-se que o Mecanismo de Banco de Dados do SQL Server por padrão é definido 
com o nível de isolamento READ COMMITTED, podendo ser redefinido pelo programador 
caso haja necessidade. Os níveis diferenciam na capacidade de mais usuários acessa-
rem os dados simultaneamente, havendo para tanto a necessidade de mais recursos 
para aumentar o nível de isolamento. O nível mais baixo de isolamento é a leitura não 
confirmada, que permite ler dados de outras transações que ainda não deram COMMIT, 
ou foram finalizadas, fazendo o que chamamos de leitura suja. As principais diferenças 
de um nível para o outro são destacadas na Tabela 2.
Quando, então, redefinir o nível de isolamento de uma transação?
Recomendo que mantenha-se o nível de isolamento padrão do SGBD que esteja traba-
lhando. Porém, há situações em que um sistema pode ter a necessidade de uma granu-
laridade menor, como um sistema de decisão de investimento em bolsas de ações. Siste-
mas especialistas precisam tomar decisões ou indicar melhores opções que demandam 
uma programação mais hard core, digamos assim. De qualquer forma, entenda qual a 
Ao se trabalhar com banco de dados em nuvem, outros níveis de isolamento 
podem ser configuráveis. Saiba mais pesquisando sobre os níveis de isolamen-
to que controlam o comportamento de bloqueio e do controle de versão de li-
nha das instruções Transact-SQL emitidas por uma conexão com o SQL Server.
Ampliando o foco
Exemplo de aplicação de nível de isolamento em uma transação:
Se uma transação estiver em um nível de isolamento mais baixo, Leitura não 
confirmada. Suponha que tenhamos duas transações a serem executadas, a 
Transação A e a Transação B. A transação A atualize uma linha. A transação B 
lê a linha atualizada antes que a transação A confirme a atualização, antes de 
executar o COMMIT. Se a transação A der um ROLLBACK, a transação B terá 
dados de leitura que são considerados nunca existentes.
Exemplo
76
necessidade de manipulação do dado para decidir a real necessidade de mudança no 
nível da transação. 
Sendo assim, a partir das cláusulas SET TRANSACTION são definidos os modos de 
acesso que podem ser READ (somente leitura), WRITE (somente atualização) e READ 
WRITE (ambos – default) e da cláusula ISOLATION LEVEL, por meio da qual são defi-
nidos os níveis de isolamento, SERIALIZABLE (transação executa com completo iso-
lamento – default, para alguns SGBDs), READ COMMITTED (onde transações só leem 
dados gravados. No entanto, outras transações podem escrever em dados lidos por 
demais transações).
Para saber mais informações sobre os diferentes níveis de acesso, assim como 
os fenômenos de leitura suja, leitura não repetível e fantasma faça a leitura 
além das informações reportadas nesta unidade e nas leituras complemen-
tares indicadas na midiateca. Recomendamos que busque mais informações 
sobre os níveis de isolamento da transação, como eles podem ser associados 
com a linguagem de programação com que esteja trabalhando, nas formas de 
conexão com o BD e na programação em camadas.
Ampliando o foco
77
Instrução Savepoint
A instrução Savepoint marca um ponto de gravação dentro da transação atual, sendo 
utilizada para dividir uma transação em partes menores. Identificar um ponto em uma 
transação tem o objetivo principal de possibilitar que, futuramente, você possa efetuar 
um ROLLBACK para determinado ponto salvo na transação.
Os pontos de salvamento são úteis em situações em que erros são improváveis. E, dessa 
forma, os comandos de ROLLBACK poderiam voltar àquele estado tratado, pertinente-
mente, como ponto de salvamento e retorno para o estado dos registros sem impacto de 
consistência de dados. As atualizações e reversões são operações consideradas caras, 
pois demandam o bloqueio de vários recursos. Logo, pontos de salvamento só serão 
eficientes se a probabilidade de encontrar o erro for baixa e o custo de verificar a validade 
de uma atualização com antecedência for relativamente alto. 
A sintaxe do SAVE ou SAVEPOINT
SAVE { TRAN | TRANSACTION } { savepoint_name | @savepoint_variable } [ ; ] 
Argumentos do Savepoint
O savepoint possui dois argumentos: 
savepoint_name e @savepoint_variable.
O savepoint_name refere-se ao nome que será atribuído ao ponto de salvamento. Des-
taco que os nomes utilizados neste argumento devem estar de acordo com as regras 
para identificadores, sendo as mesmas limitadas a 32 caracteres. Ele é case sensitive, ou 
seja, diferencia maiúsculas de minúsculas.
Já o @savepoint_variable refere-se ao nome de uma variável definida pelo usuário, que 
contém um nome de ponto de salvamentoválido. Ressalto também que, por tratar-se 
de uma variável, ela precisa ser declarada com o tipo de dados char, varchar, nchar ou 
78
nvarchar, tipos específicos para armazenamento de caracteres. Recomendo que sejam 
utilizados até 32 caracteres na declaração desta variável, já que, apesar de permitir a uti-
lização de mais caracteres, apenas os primeiros 32 caracteres são usados.
Em uma tabela conta temos os campos saldo e conta, em que o saldo arma-
zena o saldo da conta corrente ou poupança e a conta armazena o número da 
conta corrente ou poupança. Temos também uma tabela chamada LogSaldo 
com os campos saldoguardado e contaguardada. Queremos atualizar o valor 
do campo saldo para os registros com valores menores do que o valor 20. 
Logo, identificamos que vamos fazer uma atualização (saldo=1000) de acordo 
com a condição informada (saldo<20). 
Na transação a seguir estamos criando um save point chamado de INS_SAL-
DOLOG para garantir que as informações antigas sejam inseridas na tabela de 
logsaldo, garantindo a integridade das informações, caso futuramente seja fei-
ta alguma alteração que não deveria ocorrer.
BEGIN TRANSACTION
 UPDATE FROM conta
 SET saldo= 1.000
 WHERE saldo < 20
SAVE TRANSACTION INS_SALDOLOG 
INSERT INTO logsaldo 
(SELECT saldoguardado, contaguardada 
 From logsaldo)
COMMIT
Exemplo
Para versões do SQL Server 2014 e anteriores será necessário verificar nas 
documentações de versões anteriores.
Importante
79
Outro exemplo de aplicação de Savepoint.
Ao se trabalhar com transações é preciso destacar que o SQL Server efetua bloqueios de 
recursos que demandem o menor recurso disponível. Por exemplo, se há uma atualização 
de registro de uma tabela, somente aquele registro é bloqueado e não toda a tabela, liberan-
do, assim, acesso aos demais registros da tabela envolvida em uma transação.
Em uma tabela Setor com os campos codset, para armazenar o código do 
setor, descricao e codgerente, para armazenar o código do gerente de cada 
setor, deseja-se fazer a inserção de um novo setor e salvar os dados. Proposita-
damente, adicionei um comando para apagar todos os registros de outra tabela 
chamada Funcionario. No entanto, quero apenas que o setor seja inserido e o 
restante do código seja executado, dando um aumento de 5% a todos os fun-
cionários do setor criado conforme código abaixo:
INSERT INTO setor (codset, descricao, codgerente) 
 VALUES (15, ‘Auditoria Interna’, 7); SAVEPOINT ponto1; 
DELETE FROM Funcionario; 
ROLLBACK TO SAVEPOINT ponto1; 
UPDATE Funcionario 
 SET salario = salario * 1.05 WHERE codset = 2; 
COMMIT;
Dessa forma, o comando INSERT é executado e salvos os dados das tabelas 
envolvidas na transação conforme comando SAVEPOINT no ponto1, executado 
o comando DELETE, sendo que, como existe um comando ROLLBACK na pró-
xima linha, este desfaz tudo que foi executado antes do último ponto de salva-
mento (ponto1), desfazendo a exclusão dos registros da tabela Funcionario, em 
seguida atualizando o salário e gravando os dados no BD, finalizando o estado 
da transação. 
Exemplo
80
Arquitetura do Gerenciador de Banco de Dados
A arquitetura de um SGBD é fundamental para a execução de transações. Ressalto que ela 
tem o objetivo principal de garantir as propriedades das transações ACID, e que contempla, 
entre outros componentes, o Gerente de Transações, que objetiva controlar o escalona-
mento dos recursos utilizados e bloqueados entres as transações, conforme a Figura 2.
Figura 2: Arquitetura do gerenciador de Banco de Dados.
Fonte: Elaborada pela autora (2020).
Deadlock refere-se ao controle de concorrência, ou seja, em BD, quando mais 
de uma transação disputa os mesmos recursos. Isso fica explícito com o co-
mando DML. A manipulação de dados requer bloqueios e liberação de dados o 
tempo todo. Ou seja, imagine que há vários usuários tentando acessar um mes-
mo registro. Logo, é necessário que exista uma organização com bloqueios e 
prioridades. Se o usuário A está fazendo uma alteração, o usuário B só poderá 
fazer outra alteração após o primeiro (usuário A) finalizar. Dessa forma, o SGBD 
deve controlar o acesso ao mesmo recurso e gerenciar a concorrência.
Ampliando o foco
Gerente 
de Buffers
Gerenciador
de Arquivos
Otimizador 
de Consultas
Gerente de 
Recuperação 
Falhas
Verificação de
Integridade
Gerente de 
Transações
Scheduler
Gerente de Dados
Bando de Dados e 
Dicionário de Dados
Código objeto 
de programas
Processador 
de consulta
Gerenciador 
Dicion. Dados
Autorização
de Acesso
Processador
de Comandos
81
Vamos imaginar uma situação hipotética em que duas transações T1 e T2 desejam atua-
lizar (comando UPDATE) um dado (campo X) em uma mesma tupla (linha onde o campo 
código= HIP001) de uma tabela (TabX). O SGDB fará uso de vários componentes para 
que a execução das duas transações possa ser concluída. 
Para tanto, é verificado, por meio da Autorização de Acesso, se cada uma tem aces-
so aos dados desejados (pois o usuário pode não ter direito de escrito em determina-
dos itens). Processar os comandos, checando sua sintaxe e retornando linhas de erros, 
quando for o caso. Em paralelo fazer a verificação de Integridade, ou seja, se os dados 
vão permanecer confiáveis após a execução do código.
Caso o módulo de Otimizador de Consultas esteja ativo o SGBD gerará relatório com 
sugestões de melhoria de eficiência do código. Fará o escalonamento a partir do Sche-
duler, ou seja, um gerenciamento de qual dado será acessado e em que ordem de prio-
ridade. Em seguida, passará informações para o Gerente de Transações para controlar 
os recursos e transações. Quando são acionados os comandos de ROLLBACK em uma 
transação é acionado o Gerente de Recuperação de Falhas, para que possa enviar e 
tratar as falhas, podendo ser de hardware ou de software, e o Gerente de buffers, para 
que possa retornar os dados de memória ou paginação.
Para saber mais sobre Stored procedure e Trigger pesquise e leia sobre CLR 
(Common Language Runtime). Pratique, crie, compile, aplique passagens de 
variáveis e agendamentos a partir de condições de inclusão, alteração ou outra 
necessidade que uma situação venha a demandar.
Ampliando o foco
Para ampliar o seu conhecimento veja o material complementar da Unidade 4, 
disponível na midiateca.
MIDIATECA
82
Para ilustrar o conceito de transação, trago o exemplo clássico de transferência 
de dinheiro de uma conta para outra. Suponha que o correntista Pedro pretenda 
transferir R$ 500,00 de sua conta bancária para a conta da correntista Maria. 
Uma transferência corresponde a uma retirada de um valor X em uma conta 
(um débito) e um depósito do mesmo valor X em outra conta (um crédito).
Para execução do débito e do crédito, é necessária a aplicação de operações 
matemáticas de subtração e soma por meio do comando de manipulação de 
dados, o UPDATE, no campo saldo da tabela conta. Para tanto, sabemos que o 
número da conta de Pedro é igual a “2032” e a conta de Maria é igual a “3402”.
UPDATE conta 
 SET saldo = saldo - 500 
WHERE conta = “2032” 
UPDATE conta 
 SET saldo = saldo + 500 
WHERE Conta = “3402”
O primeiro UPDATE realizaria a operação na conta de origem (Pedro) e o segun-
do UPDATE faria a atualização na conta de destino. O que, porém, aconteceria 
se, devido a algum problema na rede de computadores, apenas o primeiro UP-
DATE fosse executado? 
Considerando que apenas o primeiro Update fosse executado, Pedro ficaria com 
menos R$ 500,00 em sua conta, enquanto o Maria ficaria com o mesmo saldo. 
Ou seja, não haveria notificação de erro ao SGBD, pois a sintaxe do comando está 
correta e ele seria executado sem problemas. No entanto, há a necessidade de 
que os dois comandos sejam executados, e não somente um deles. 
Assim, para controlar esta necessidade aplicamos uma transação. Lembram 
da Lei do Tudo ou Nada? Ou o conjunto de instruções naquele bloco é exe-
cutado ou nada é executado e o estado do BD retorna ao estado anterior. Se 
NA PRÁTICA
83
somente um dos UPDATESfosse executado dentro de uma transação, esta 
informaria que ocorreu uma falha e o controle de falhas do SGBD faria retornar 
os dados à situação anterior à execução da transação. De que forma? Um erro 
seria guardado na variável @@ERROR, a arquitetura do SGBD que está fazendo 
o gerenciamento desta transação envia para tratamento de falhas, que efetua o 
ROLLBACK e volta à situação anterior ao início da transação.
Lembrando a sintaxe que pode ser utilizada em uma transação com tratamento 
da variável @@error: 
BEGIN TRANSACTION 
 comando SQL(INSERT,UPDATE,DELETE) 
IF @@ERROR <> 0 
 ROLLBACK 
ELSE 
 COMMIT 
Para a necessidade da transferência das contas de Pedro e Maria o código po-
deria ficar como o que segue:
BEGIN TRANSACTION 
UPDATE conta 
 SET saldo = saldo – 500
WHERE conta = “2032” 
UPDATE conta 
 SET saldo = saldo + 500 
WHERE Conta = “3402”
IF @@ERROR <> 0 
 ROLLBACK 
ELSE 
 COMMIT 
// A depender da versão utilizada do SQL pode ser utilizado o comando GO ao 
final do código
84
Esses comandos nos permitem realizar o controle de início, fim e registro das 
transações, de modo a concretizar aquelas propriedades ACID (Atomicidade, 
Consistência, Isolamento e Durabilidade) que já vimos. Garante atomicidade e 
consistência dos dados. Quando não implementam-se as operações dentro 
de uma transação, o processamento será executado a cada chamada, consu-
mindo mais recursos de processamento e de armazenamento e, ao se imple-
mentar dentro de uma transação, a operação já estará compilada e demandará 
menos recursos.
85
Resumo da Unidade 4
Esta unidade contemplou a sintaxe e a propriedades das transações, assim como 
suas aplicações a partir de procedimentos e triggers. Os conceitos e detalhes de 
bloqueios de recursos e dados, assim como nível de isolamento e arquitetura de um 
SGBD foram destacados.
As Transações podem envolver vários conceitos devido a suas diversidades de 
aplicações, possibilidade de resoluções, podendo haver formas diferentes de 
programação e melhorias de aplicabilidade. Procedimentos armazenados, que 
também são transações, são semelhantes às estruturas lógicas em outras lin-
guagens de programação. O tratamento de exceções, estruturas de repetição e 
estruturas de seleção seguem a mesma linha de raciocínio, havendo mudanças 
de sintaxe. 
A otimização de recursos com a criação de procedimentos e de triggers aper-
feiçoam muito o tempo de resposta e alocação de recursos para processamen-
to destes. Considere que qualquer tipo de acesso a dados é uma transação, o 
que mudará é a forma de gerenciamento, passagem de parâmetros, chamadas 
e disparos a partir de situações pré-configuradas. Transações trazem um mun-
do de possibilidades na programação backend e na interface de comunicação 
com o frontend.
CONCEITO
86
Referências 
DAMAS, L. SQL - Structured Query Language. Rio de Janeiro: LTC. ISBN: 9788521632450. 
Minha Biblioteca.
ELMASRI, R.; NAVATH, Sistemas de Banco de Dados. Rio de Janeiro: Person. Minha 
Biblioteca.
HEUSER, C. A. Projeto de Banco de Dados, 6. ed. Porto Alegre: Bookman, 2011. ISBN: 
9788577804528. Minha Biblioteca.
MACHADO, F. N. R. Banco de Dados - Projeto e Implementação. São Paulo: Saraiva. 
ISBN: 9788536518978. Minha Biblioteca.