ADM DE BANCO DE DADOS CAP_1-2

Prévia do material em texto

Adriana Bastos da Costa 
Fabiano Carvalho Gomes
Jeanfrank Teodoro Dantas Sartori
Marciano Lourenço da Silva Gonçalves
Márcio dos Santos
Sidartha Azevedo Lobo de Carvalho
ADMINISTRAÇÃO DE BANCO DE DADOS
Administraç�o de Banco de Dados20
OBJETIVOS DO CAPÍTULO
• Compreender a importância das informações em um ambiente empresarial. 
• Distinguir os diferentes tipos de sistemas gerenciadores de banco de dados 
existentes.
CAPÍTULO 1
A importância da informação e 
Sistemas Gerenciadores de Banco de Dados
Marciano Lourenço da Silva Gonçalves 
TÓPICOS DE ESTUDO
1 Importância de um Banco de Dados 3 Tipos de SGBD
• Uso estratégico e valor agregado à 
informação.
• Características das aplicações 
usuárias.
• Hierárquico.
• Relacional.
• Orientado a objetos.
• Objeto relacional.
2 Sistema de Gerenciamento de 
Banco de Dados (SGBD)
4 Modelo NoSQL
• O que é um SGBD?
• Vantagens e Desvantagens.
• Orientado a documento.
• Valor-chave.
• Orientado a coluna.
• Orientado a grafo.
21Administraç�o de Banco de Dados
Conte�tuali�ando o cenário
Antes dos computadores, o armazenamento de informações era realizado com o uso de 
papel, que era então acondicionado em armários. Quando surgiram os primeiros computa-
dores, percebeu-se que tal armazenamento poderia ser realizado de forma mais eficiente. 
Com o uso, por exemplo, de um Sistema Gerenciador de Bancos de Dados (SGBD) é possível 
tornar a tarefa de armazenamento, consulta e modificação de dados mais prática e segura, 
já que esses sistemas oferecem mecanismos para tal.
As empresas investem altos custos em banco de dados que possam trabalhar com um 
grande volume de informações mantendo a sua integridade, disponibilidade e rapidez no 
acesso. Mas será que vale a pena investir tanto em um sistema de banco de dados?
Administraç�o de Banco de Dados22
1.1. Import�ncia de um Banco de Dados
Os bancos de dados surgiram da necessidade de melhores alternativas para o arma-
zenamento de informações, principalmente, as que agregam, de alguma maneira, valor aos 
negócios. Com o passar dos anos, o uso de papel não era mais suficiente, muito menos efi-
ciente para tal tarefa, sendo assim, computadores o substituíram na realização desta ativi-
dade de armazenamento de informações.
Novas tecnologias surgiram, tornando o uso de computadores mais acessível, de 
modo geral. Com isso, a quantidade de dados a serem armazenados aumentou de forma 
exponencial, fazendo com que maiores cuidados sejam tomados com a sua manipulação, já 
que na era digital a informação se tornou uma moeda de grande valor.
1.1.1. Uso estratégico e valor agregado � informaç�o
Na era digital, a informação tem sido considerada como um dos principais bens que 
uma organização possui. Com a globalização e o crescimento no uso de novas tecnologias, 
as empresas passaram a ter como concorrentes não apenas seus vizinhos, mas empresas 
do mundo inteiro. E as informações que a empresa possui podem ser um diferencial.
Muitas vezes a própria informação torna-se um produto que é vendido, de forma 
legal ou não. Não é incomum ler notícias de vendas ilegais de informações dos usuários de 
redes sociais, dentre outros serviços, para empresas privadas com o intuito de obter vanta-
gens comerciais, ou até mesmo políticas.
Ao manter informações em sites, muitos usuários concedem o uso das mesmas por ter-
ceiros. Por isso, se realizamos uma pesquisa em um site de buscas sobre um determinado pro-
duto, ao acessar uma rede social ou e-mail, aparecem propagandas exatamente do produto 
pesquisado. Isso torna o processo de divulgação mais direcionado e, de certa forma, efi caz.
A partir das informações que uma empresa possui, é possível direcioná-la para uma 
maior produtividade, melhor aproveitamento de recursos e, consequentemente, maior 
ganho de rendimentos, cumprindo assim seus objetivos.
Curiosidade
Supermercados disponibilizam aplicativos para celular nos quais é possível 
visualizar ofertas diárias. Além disso, de acordo com os produtos comprados, os descon-
tos são personalizados. Com o uso dessas informações, as empresas fidelizam seus clientes 
garantindo assim uma maior lucratividade.
23Administração de Banco de Dados
De acordo com Beal (2004), existem algumas leis que definem a informação como 
sendo um bem que de fato agrega valor às empresas. São elas:
• 1ª Lei: A informação é compartilhável: a informação pode ser compartilhada, diferen-
temente dos bens físicos de uma empresa. Tais informações são úteis, pois servem 
de integração entre todos os envolvidos na empresa. Além disso, o compartilhamento 
externo da informação ganha valor à medida que mais usuários a utilizam.
• 2ª lei: O valor da informação aumenta com o uso: a informação não passa por depre-
ciação, pelo contrário, à medida em que vai sendo utilizada, aumenta seu valor.
• 3ª Lei: A informação é perecível: a informação possui uma “data de validade”. É pre-
ciso se manter sempre atualizado. Uma empresa que faz uma pesquisa de mercado 
para aumentar sua captação de clientes, precisa, se ainda tiver o mesmo objetivo, 
que a mesma seja refeita constantemente em busca de novas informações.
• 4ª Lei: O valor da informação aumenta com a precisão: as informações necessitam 
ter o máximo de precisão possível, já que a falta de exatidão pode gerar prejuízos 
para a empresa.
• 5ª Lei: O valor da informação aumenta quando há combinação de informações: a infor-
mação passa a ter maior valor quando a mesma é compartilhada e combinada com os 
diversos setores da empresa (marketing, financeiro, desenvolvimento, entre outros).
• 6ª Lei: Mais informação não é necessariamente melhor: Grandes quantidades de 
informação precisam ser filtradas para que, dentro de um conjunto maior, seja 
possível obter apenas as informações que sejam de fato relevantes à empresa. 
Todas as grandes empresas trabalham com a Tecnologia da Informação (TI) que é res-
ponsável, por meio da combinação entre hardware e software, por fornecer mecanismos 
que auxiliam a empresa de modo geral, incluindo a coleta, manipulação e estudo de dados, 
de forma que eles possam guiar a empresa em certos direcionamentos.
A tecnologia oferece algumas ferramentas que podem auxiliar nessas tarefas, tais como:
• Business Intelligence: um conjunto de ferramentas que captura dados e fornece, de 
forma inteligente, apoio nas decisões da empresa;
• Datawarehouse: armazena em um único espaço informações geradas por diver-
sas fontes da organização. Com isso, é possível realizar análises por meio de 
padronizações;
• Enterprise Resource Planning: auxilia na minimização do desperdício de mão de 
obra e custos operacionais;
• Customer Relationship Management: fornece à empresa dados dos clientes que são fieis 
a ela. Dessa forma, gera um padrão de interesse para futuras estratégias de marketing.
Administração de Banco de Dados24
Sabendo que a informação possui tanto valor, é de fundamental importância man-
tê-la em segurança. Os computadores são o meio mais utilizado hoje em dia para o arma-
zenamento das informações. Os sistemas especializados em armazenamento de dados 
possuem mecanismos que garantem segurança tanto no armazenamento quando nas tran-
sações que acorrem com as informações. Limitar o acesso apenas a usuários autorizados é 
um dos mecanismos mais utilizados na segurança das informações, para isso usa-se, geral-
mente, o já conhecido sistema de login e senha.
Além disso, como por legislação todos os dados dos usuários e possíveis vazamentos 
são de responsabilidade da empresa, é imprescindível que outros métodos sejam implan-
tados, como softwares de monitoramento de tráfego e de backups, além da elaboração de 
um plano de contingência para solucionar eventuais problemas.
Invasões a bases de dados é uma nova modalidade de crime que vem ganhando espaço, 
o que frisa mais ainda a necessidade de manter as informações em um ambiente seguro.
Gestão da informação e segurança de dados
É possível perceber que a gestão da informaçãoé um assunto extenso e complexo, 
pois envolve organizar os dados, armazenar e utilizar estes dados de forma a agregar valor 
para as organizações, apoiando a gestão e a tomada de decisão. 
O dado é a unidade mais básica de um sistema de informação, ou seja, pode ser en-
tendido como a observação de um fato, como um registro em forma primária de um fato. 
A informação é o dado organizado. Explicando um pouco melhor, podemos entender 
que quando os dados estão relacionados, organizados, contextualizados e permitem uma 
interpretação, eles são classificados como informação, pois fazem sentido para quem os 
usa. Dessa forma, é possível relacionar o nome do cliente com o pedido que ele faz em de-
terminada data. Esse é um conjunto de dados organizado, que faz sentido para ser usado 
como uma informação relevante para o negócio. 
O conhecimento é o nível mais alto em uma hierarquia de gestão da informação, 
onde temos como níveis inferiores o dado e a informação, nesta ordem. O conhecimento é 
saber usar as informações para melhorar o desempenho dos negócios, para ser mais com-
petitivo e oferecer aos seus clientes melhores experiências. É o que vemos em vários sites 
de comércio eletrônico que estudam nossas preferências de compras e nos oferecem vários 
produtos de acordo com estas preferências.
Podemos também explorar um pouco sobre como as informações podem ser estrutu-
radas em níveis, tais como:
Informação operacional: são as informações necessárias para que as decisões em ní-
vel operacional sejam tomadas. Por exemplo, quantas peças precisam ser produzidas no 
dia de hoje. 
25Administração de Banco de Dados
Informação tática: são as informações necessárias para que as decisões em nível ge-
rencial sejam tomadas. Por exemplo, no mês de dezembro, como teremos uma baixa de 
produção, podemos planejar as férias de metade da equipe de produção. 
Informação estratégica: são as informações necessárias para que as decisões em ní-
vel executivo/estratégico sejam tomadas. Por exemplo, para aumentar o faturamento em 
20%, baseado no faturamento atual da empresa, precisamos conquistar 5 novos clientes 
com demandas de no mínimo R$ 100.000,00/ mês. 
A transformação do dado em informação pressupõe a organização e significação 
destes dados em uma informação útil para ser usada. Logo, este primeiro movimento de 
transformação do dado em informação requer a definição da utilidade do dado, a categori-
zação para apoiar a organização dos dados, deve permitir a análise matemática ou estatís-
tica dos dados, além de permitir a síntese e análise dos dados. 
A transformação da informação em conhecimento requer que a análise para estrutu-
ração dos dados tenha sido completa e adequada e que os dados estejam organizados de 
forma a conter todas as informações necessárias para gerar o conhecimento. Para que o 
conhecimento seja efetivo, é preciso que as informações possam ser comparadas para ge-
rar conclusões e permitam conexões fáceis com novas informações que surgem ao longo 
do tempo.
Muitas vezes, o conhecimento requer novas informações, e o fluxo pode então ser 
realizado de forma inversa. Ou seja, o conhecimento exige uma nova informação que por 
sua vez precisa de novos dados para ser gerada. E este é um movimento constante, que 
deve acompanhar o movimento das organizações, que estão o tempo todo inovando e se 
reinventando, e para isso, precisam que os sistemas de informação também evoluam com 
rapidez para apoiar o crescimento dos negócios. 
Quando falamos em segurança da informação, existe uma norma ISO que é 
especializada no assunto e direciona as boas práticas que devem ser seguidas para 
minimizar os riscos relacionados com problema de segurança. Estamos falando da norma 
ISO/IEC 27000 (http://www.abnt.org.br/noticias/5777-iso-iec-27000-norma-internacional-
de-seguranca-da-informacao-e-revisada). De acordo com a ISO/IEC 27000, segurança é 
a minimização do risco associado às atividades de computação, incluindo a interconexão 
entre computadores e demais aspectos físicos e humanos. É importante definir uma 
política de segurança, com o objetivo de define os controles lógicos e físicos necessários 
para assegurar um determinado nível de disponibilidade dos sistemas, confiabilidade 
dos dados e servir de referência para as ações de treinamento dos usuários e demais 
procedimentos de segurança. Mas, mesmo tomando as medidas de proteção necessárias, 
não existe segurança ABSOLUTA. Ou seja, sempre poderão existir vulnerabilidades. 
Administração de Banco de Dados26
1.1.2. Características das aplicações usuárias
Existe uma diferença conceitual entre dado e informação. Dado é algo em sua forma 
bruta, que fora de contexto não faria sentido. Já a informação é um conjunto de dados 
combinados que compõem um contexto. Por exemplo, se pegarmos os dados “7” e “setem-
bro”, estes isolados não significam nada. Mas se usarmos estes dados na frase “No dia 7 de 
setembro é comemorada a independência do Brasil”, agora sim temos uma informação.
No cotidiano, é possível observar que existem diversos tipos de dados, como núme-
ros, caracteres, imagens, sons, entre outros. Para cada tipo de dado existem maneiras 
diferentes de armazenamento e manipulação, daí surgiram bases de dados que trabalham 
especificamente com um ou alguns tipos de dados, como as bases multimídia, geográficas 
ou em tempo real, por exemplo.
A princípio, em bancos de dados computacionais, as informações relevantes para 
armazenamento eram basicamente números e caracteres. Com o avanço da tecnologia, 
novas aplicações foram desenvolvidas com uma abordagem que necessitava de dados 
variados. À medida que novos aparelhos e aplicativos foram desenvolvidos, tais como os 
que possuem mecanismos de captura de imagem e áudio, percebeu-se que bases de dados 
que suportavam apenas números e caracteres não eram mais viáveis. Foram criadas então 
as bases de dados multimídia. Esse tipo de base é utilizado, por exemplo, na construção de 
sites nos quais é possível ter acesso a textos, vídeos, fotos e áudio.
Existem também bancos de dados geográficos, que trabalham com informações de 
grande complexidade e com a possibilidade de armazenar enormes quantias de dados geo-
métricos, tais como mapas e imagens de satélite, possibilitando desta forma a análise de 
consultas geográficas.
Em determinados tipos de situação é imprescindível que os dados sejam atualizados 
constantemente. Para dar suporte a este tipo de aplicações surgiram os bancos de dados 
em tempo real. Este tipo de banco precisa garantir a integridade dos dados mantendo a 
sua consistência constantemente. Esse tipo de banco de dados é utilizado na aviação ou na 
automação hospitalar, por exemplo.
Pausa para refletir
Sabemos que diversos tipos de dados distintos são armazenados nos bancos. Mas como é 
realizado esse armazenamento?
27Administração de Banco de Dados
De acordo com Beal (2004), a tecnologia da informação fornece inúmeras vantagens, 
para uma empresa, através das suas aplicações, podendo assim ser realizado uma maior 
gestão estratégica da informação. A autora cita algumas soluções tecnológicas, dentre elas 
podemos destacar:
• VOIP (Voz sobre IP): mecanismo que permite a transmissão de voz por canais digi-
tais. Com isso a empresa pode utilizar a mesma infraestrutura que já utiliza em 
sua rede de computadores para realizar ligações e até mesmo chamadas de vídeos 
pela Internet. O que ocasiona uma redução de custos para a empresa.
• Wireless: as redes sem fio permitem que serviços em uma rede sejam acessados 
sem a necessidade de uma infraestrutura física (cabos). O que permite uma maior 
mobilidade e economia dentro da empresa.
• GED (Gestão Eletrônica de Documentos): outra tecnologia que pode auxiliar uma 
empresa é a GED. Com este tipo de mecanismo é possível armazenar toda a docu-
mentação da empresa em formato digital. Tornando assim mais ágil e seguro seu 
armazenamento e posterior consulta.A correta utilização da tecnologia da informação, pode de fato, ser um agregador de 
valor a qualquer empresa.
Gerenciamento de Espaço
A qualidade dos dados é o ponto alto de um bom gerenciamento de banco de dados, 
o que envolve também o gerenciamento do espaço utilizado e disponível, de forma a evitar 
perdas de dados. 
Um amontoado de informação sem sentido ou ainda informações pela metade de 
nada servem para a empresa, podem consumir espaço de forma desnecessária, dificul-
tando a administração de um banco de dados. 
Portanto, para se organizar e gerenciar um banco de dados, é preciso ter em mente 
alguns fatores:
• o sistema a ser utilizado;
• o domínio da sua linguagem;
• a disposição humana e tecnológica para acomodar esse banco;
• a estratégia de armazenamento desses dados.
Todos esse fatores devem ser levados em conta para garantir uma gestão eficiente do 
espaço necessário para que o banco de dados funcione de maneira adequada.
Administração de Banco de Dados28
1.2. Sistema de Gerenciamento de Banco de Dados (SGBD)
Os bancos de dados nem sempre foram ou são criados e mantidos em meio eletrô-
nico. Um catálogo telefônico, por exemplo, é uma base de dados impressa que oferece a 
possibilidade de realizar consultas a diversos telefones de estabelecimentos comerciais ou 
residenciais. E mesmo que seja utilizado um computador para tal, como uma planilha ele-
trônica, percebe-se que é possível utilizar mecanismos menos elaborados para manter uma 
base de dados pequena.
Os primeiros bancos de dados utilizavam o sistema de arquivos para o armazena-
mento e manipulação dos dados. Esses sistemas apresentavam diversos problemas, tais 
como: inconsistência e redundância de dados, dificuldade de acesso, problemas de inte-
gridade e atomicidade, dentre outros. Para solucionar esses problemas, surgiu o Sistema 
Gerenciador de Banco de Dados (SGBD).
1.2.1. O que é um SGBD?
Os Sistemas Gerenciadores de Bancos de Dados são um conjunto de ferramentas 
que permitem a manipulação de dados em meio computacional. “O SGBD é, portanto, um 
sistema de software de propósito geral que facilita o processo de definição, construção, 
manipulação e compartilhamento de banco de dados entre vários usuários e aplicações” 
(ELMASRI; NAVATHE, 2005, p. 3).
Os sistemas de bancos de dados oferecem aos usuários três níveis de abstração: nível de 
visão, nível conceitual e nível físico. Estes três níveis de abstração são representados a seguir:
Níveis de abstração
Visão 1 ... Visão n
Físico
Conceitual
Fonte: SILBERSCHATZ, 2006. (Adaptado).
©
 D
TC
O
M
29Administração de Banco de Dados
O primeiro nível fornece uma visão abstrata dos dados, sendo assim, os usuários não 
necessitam entender como de fato são realizadas internamente as consultas, inserções, atuali-
zações ou exclusões dos dados. Na verdade, este nível fornece um subconjunto dos dados que 
compõem a base completa, podendo até apresentar dados que nem mesmo estejam no banco.
O nível conceitual apresenta os dados que estão armazenados no banco e a relação 
entre eles. Isso se dá por meio de estruturas, geralmente de fácil compreensão, que podem 
ser melhor elaboradas e implantadas no nível físico, que é o menor nível de abstração, e 
que descrevem como os dados são armazenados de fato.
Um sistema de banco de dados é composto por alguns elementos e suas interações. 
O diagrama a seguir apresenta de modo geral a sua estrutura.
Estrutura do SGBD
Sistemas de
Banco de
Dados.
Usuários
Programas
Banco de dadosMetadados
SGBD
Fonte: Adaptado de ELMASRI e NAVATHE, 2005.
Em um sistema de banco de dados os usuários podem requisitar informações de 
uma base de dados por meio de softwares (geralmente com maior nível de abstração) sem 
necessitar conhecer as etapas necessárias para a realização desta tarefa. Este usuário pode 
ser tanto um usuário final quanto programadores. 
Os programas utilizados pelos usuários se encarregam de acessar o SGBD, que por 
sua vez proporciona o acesso aos dados e ao catálogo, que são os metadados. Os metada-
dos tem por finalidade armazenar os esquemas das bases mantidas pelo SGBD.
©
 D
TC
O
M
Administração de Banco de Dados30
1.2.2. Vantagens e desvantagens
Segundo Elmasri e Navathe, um bom SGBD deve ter características como:
• redundância: um dos grandes problemas dos sistemas de arquivos – sistemas que 
antecederam os SGBDs – era a redundância de dados. Lá os arquivos eram mantidos 
por vários usuários (programadores) e os mesmos dados podiam constar em arquivos 
diferentes. Principalmente quando se trata de uma quantidade considerável de dados, 
a redundância consome memória e processamento sem necessidade, devendo assim 
ser evitada. Um exemplo simples: suponhamos que o cliente de banco tenha uma 
conta corrente e uma conta poupança. As informações das contas em si são distintas, 
mas as informações do cliente permanecem as mesmas para ambas as contas. Em um 
sistema de arquivos, possivelmente, os dados do cliente estariam duplicados. A redun-
dância também afeta a integridade dos dados, suponhamos que o cliente do banco 
mudou de endereço e pede para atualizar suas informações. Esses dados devem ser 
atualizados tando para a conta corrente quando para a conta poupança, caso contrário 
os dados ficariam com inconsistências. Com os SGBDs é possivel evitar ou controlar a 
redundância de forma que as inconsistências não ocorram;
• segurança: sabemos que nem todos os usuários devem ter acesso à base de dados 
completa. Existem alguns dados que devem e podem ser acessados por usuários 
especificos, que utilizam uma senha para tal. Os SGBDs fornecem mecanismos para 
garantir que usuários, ou grupos deles, tenham acesso restrito à base de dados;
• processamento eficiente de consultas: nos sistemas de arquivo, caso surgisse 
uma necessidade de consulta que não estivesse prevista no sistema, seria neces-
sário reprogramá-lo para obter os dados desejados. Em um sistema bancário, por 
exemplo, é possivel realizar a consulta de clientes pelo número da conta, mas não 
pelo seu cadastro físico. No entanto, em certo momento sentiu-se a necessidade 
de encontrar um cliente pelo seu CPF. Sendo assim, um novo programa deve ser 
desenvolvido para gerar a consulta necessária. Os SGBDs além de solucionarem 
este problema, ainda implementa os índices, que são arquivos auxiliares, com o 
objetivo de aumentar a velocidade das pesquisas;
• sistemas de recuperação: outro problema dos sistemas de arquivos era a atomi-
cidade. As operações em um banco de dados precisam ser atômicas, ou seja, ou 
ocorrem por completo ou não ocorrem. Ao realizar um saque em um banco, por 
exemplo, nunca deverá acontecer de ser debitado da conta e o cliente não receber 
o valor solicitado ou vice-versa. Os SGBDs fornecem um sistema de restauração 
que evita problemas de atomicidade. Caso ocorra alguma falha em uma transação, 
o banco é restaurado para o ponto exatamente anterior ao início dela;
31Administração de Banco de Dados
• visões: o SGBD fornece a possibilidade de visões diferentes para usuários distintos. 
Os usuáros casuais não necessitam compreender a linguagem técnica dos progra-
madores, sendo assim são fornecidas interfaces diferentes para cada um deles.
Apesar de todas essas vantagens, dependendo do problema a ser solucionado, os SGBD’s 
apresentam alguns pontos que devem ser levados em consideração em seu uso ou não:
• custo: tratant-se de grandes empresas, a implantação de um SGBD poder ser cus-
tosa, tanto em valor quanto em tempo. Isso se dá principalmente pelo investi-
mento em softwares, hardwares e treinamentos para os usuários.
• mal projetado: se o banco de dados foi mal projetado em alguma das suas fases, o 
banco poderá apresentar diversas falhas. Nessa situação existe a necessidade de 
remodelar o banco, ocasionando assim um maior custo para sua devida utilização;
• danos: qualquer problema que aconteça diretamente no banco de dados afetarávirtualmente todas as aplicações associadas a ele.
Se o problema pode ser sanado por soluções simples e não há necessidade de acessos 
simultâneos, pode ser recomendo o uso de sistemas de arquivos.
1.2.3. Portabilidade, disponibilidade e compatibilidade
O conceito de portabilidade em banco de dados está relacionado com a flexibilidade, 
oferecida pelos principais fabricantes de gerenciadores de bancos de dados, tais como: 
IBM, Microsoft e Oracle, para que seus SGBD tenham funcionalidades compatíveis entre 
si. Portanto, é possível desenvolver aplicativos usando bancos de dados DB2, homologá-los 
em banco de dados SQL Server e instalá-los em ambientes de produção com gerenciador 
de banco de dados Oracle. 
O conceito de disponibilidade em um banco de dados está relacionado com um dos 
pilares da segurança da informação. E significa que o banco de dados precisa ser adminis-
trado de forma a garantir a maior disponibilidade de uso possível para seus usuários. Para 
isso, é preciso monitorar espaço disponível, acesso adequado ao usuários e uso correto do 
banco de dados.
 O conceito de compatibilidade é importante para garantir um bom relacionamento 
do software com versões antigas do gerenciador de banco de dados, evitando erros no 
momento de uso do software.
O nível de compatibilidade do banco de dados é uma ferramenta valiosa para ajudar 
na modernização de banco de dados, permitindo que o banco de dados seja atualizado, 
mantendo o status funcional de aplicativos e o mesmo nível de compatibilidade do banco 
de dados antes da atualização
Administração de Banco de Dados32
1.3. Tipos de SGBD
Os dados podem ser armazenados e organizados de diferentes formas. Sendo assim, 
existem tipos de SGBDs distintos que dão suporte a cada uma delas. É possível encontrar 
SGBDs de várias formas, tamanhos e valores. No mercado de banco de dados são oferecidos 
sistemas gerenciadores gratuitos, bem como alternativas com maior e melhor desempenho e 
custo elevado.
Sabendo desta variedade de SGBDs é preciso conhecer seus tipos para poder iden-
tificar qual deles melhor se adequa ao problema que se deseja solucionar. Dentre os prin-
cipais modelos de SGBDs destacam-se os hierárquicos, relacionais, orientados a objetos e 
objeto relacionais.
1.3.1. Hierárquico
O modelo hierárquico foi muito utilizado no passado como forma de organização dos 
dados em uma base. Apesar de seu uso não ser habitual nos dias de hoje, muitas aplicações 
antigas ainda utilizam o modelo hierárquico em seu sistema, já que a migração para um 
modelo relacional, por exemplo, pode acarretar riscos e alto custo monetário.
Este modelo consiste em um conjunto de registros (vários campos, contendo apenas 
um dado cada) que possuem uma ligação entre si. Os dados são representados por meio de 
uma estrutura de árvore hierárquica e é geralmente utilizado em mainframes, computado-
res de grande porte. A estrutura possui um nó raiz e a partir dele é possível gerar registros, 
que por sua vez podem ter outros registros, gerando assim a estrutura hierárquica. 
No modelo hierárquico, os nós pais podem possuir vários nós filhos, por outro lado, 
os nós filhos devem possuir apenas um nó pai. A figura a seguir ilustra o modelo:
Cliente 1
Conta Corrente.
Cliente 2
100 Maria 5000 José 3200200
©
 D
TC
O
M
33Administração de Banco de Dados
A figura representa parte da base de dados de um banco no qual são armazenados os 
dados dos clientes que possuem conta corrente. A partir do nó raiz (Conta Corrente) é possí-
vel acessar todos os clientes que do banco que utilizam este serviço. Já a partir de cada cliente 
individual é possível obter todos os seus dados pessoais. As consultas no modelo hierárquico 
se iniciam no nó raiz e se estendem até encontrar o nó que possui a informação desejada. 
Uma das vantagens deste modelo é a facilidade de consultas e atualização dos dados, 
já que as relações entre os registros são todas previamente definidas. Por outro lado, caso 
seja necessário incluir um novo campo em um dos registros, devido à rigidez em seu pro-
cesso de modelagem, todo o banco necessitaria ser remodelado.
Existe um modelo que é bastante semelhante ao modelo hierárquico, este é chamado 
de modelo de rede, que também representa os registros em uma hierarquia. Apesar das 
semelhanças, os dois se distinguem pelo fato que o modelo de rede não usa uma estru-
tura de árvore e sim de uma rede interligada de registros. Aqui nesse modelo os nós filhos 
podem possuir mais de um nó pai.
A figura a seguir como ilustra um exemplo do modelo de rede:
Conta Corrente
Maria 200
100
300 1200
5000
3200
José
Assim como o modelo hierárquico, o modelo de rede é fortemente dependente da 
sua implementação prévia, apresentando diversos problemas se tentamos adicionar um 
novo campo aos registros. Além disso, a quantidade de ligações que pode haver entre os 
registros é limitada.
1.3.2. Relacional
O modelo relacional foi desenvolvido por Edgar Codd na década de 1970 e de acordo 
com Silberschatz (2006) este é o modelo mais utilizado para uso comercial na atualidade. 
Ainda segundo o autor, este fato se dá pela simplicidade de uso deste modelo em relação a 
seus antecessores, hierárquico e de rede. Este modelo consiste em uma coleção de tabelas 
©
 D
TC
O
M
Administraç�o de Banco de Dados34
bidimensionais (compostas por linhas e colunas), chamadas de relações, que representam 
tanto os dados quanto o relacionamento entre eles.
Biografia
Edgar Frank Codd foi um matemático que nasceu em Dorset na Inglaterra 
(1923-2003). Em 1970, quando trabalhava para a IBM, propôs o conhecido modelo 
relacional. Pela sua contribuição científica ganhou o Prémio Turing em 1981 e o Prê-
mio Pioneiro da Computação em 1991.
As relações são compostas por um esquema e uma instância. O esquema define 
o nome da tabela, bem como o nome de cada coluna e seu domínio. Cada tabela de uma 
base de dados deve possuir um nome único, sendo assim, não é permitido que em uma 
mesma base de dados existam duas tabelas com o mesmo nome. 
Nas tabelas, as colunas possuem campos que são chamados de atributos, já as linhas 
possuem dados referentes a cada atributo da tabela e são chamadas de tuplas. Além disso, 
as tabelas possuem um campo chave, que tem por finalidade identificar uma única tupla e 
auxiliar na relação com outras tabelas.
Um exemplo de esquema pode ser:
Cliente (Código:inteiro, Nome: texto, Valor: real)
Neste esquema foi especificada uma tabela chamada Cliente com um código do tipo 
inteiro, um nome do tipo texto e um valor do tipo real. O conjunto de todas as linhas é a 
instância da relação. A quantidade de tuplas e seus valores podem ser alterados ao longo 
do tempo, mas o esquema da relação deve permanecer sempre o mesmo.
A tabela a seguir exemplifica o modelo relacional:
Tabela Cliente
Código Nome Valor
100 Maria 5000.00
200 José 3200.00
300 José 1200.00
35Administração de Banco de Dados
A Tabela Cliente possui três atributos (Código, Nome e Valor) e três tuplas (cada linha) 
de acordo com o esquema especificado anteriormente. 
Para garantir maior segurança na inserção, alteração e exclusão dos dados no banco, 
o modelo relacional implementa um conjunto de restrições de integridade. São elas:
• integridade de domínio: os valores dos atributos de uma relação sempre devem 
pertencer ao domínio especificado em seu esquema;
• integridade da chave: toda relação deve possuir um campo que identifique unica-
mente cada tupla. Esse atributo é chamado de chave primária. Na tabela acima, a 
chave primária é representada pelo atributo Código;
• integridade de entidade: os valores das chaves primárias sempre precisam ser 
preenchidos;
• integridade referencial: para fazer a ligação entre duas tabelas é preciso que 
ambas possuam valores em comuns, representados pelas chave primária de uma 
tabela e pela chave estrangeira da outra.
Quando alguma dessas restrições é acionada, o banco pode rejeitara ação que está 
sendo realizada (inserção, alteração ou exclusão) ou, em alguns SGBDs, tentar corrigir a 
violação.
Para exemplificar as restrições, podemos usar as seguintes tabelas:
Código_Disciplina Nome_Disciplina Nome_Aluno Código_Disciplina
1 Banco de Dados Ana 1
2 Programação Bruno 2
Carla 2
As tabelas acima estão relacionadas por meio do atributo Código_Disciplina, que é a 
chave primária da tabela Disciplina e a chave estrangeira da tabela Aluno. 
Se quisermos inserir uma nova tupla na tabela Aluno contendo os dados “Marcos” e 
“B”, respectivamente, estaríamos feriando a integridade de domínio, já que “B” não per-
tence ao conjunto dos números. Já se tentarmos adicionar uma nova tupla em Disciplina 
contendo “1” e “Engenharia de Software”, estaríamos violando a integridade de chave, pois 
já existe uma tupla que tem como valor da sua chave primária “1”.
Já ao tentarmos excluir alguma tupla da tabela disciplina, haverá violação na integri-
dade referencial, pois a tabela Aluno possui dados que fazem referência à tabela Disciplina.
©
 D
TC
O
M
Administração de Banco de Dados36
Todas essas regras de integridade auxiliam para que não existam inconsistências no 
banco de dados. Além disso, novas entradas no modelo relacional podem ser realizadas 
sem a necessidade de remodelagem do sistema inteiro, tornando-o dessa forma, um dos 
modelos mais utilizados atualmente. 
Apesar das vantagens, com a necessidade de armazenamento de dados cada vez mais 
complexos, para determinados tipos de aplicações o modelo relacional oferece um suporte ina-
dequado. Diante disso, outros modelos surgiram. Como o orientado a objetos, por exemplo.
1.3.3. Orientado a objetos
Os dados no modelo orientado a objetos são representados por objetos, sendo eles 
manipulados apenas pelos métodos da classe à qual pertencem. A ideia deste modelo se 
baseia no paradigma orientado à objetos, utilizado por algumas linguagens de programa-
ção como C++, JAVA e C#. Segundo Silberschatz: 
O termo banco de dados orientado a objetos é usado para descrever um sistema de 
banco de dados que aceita acesso direto aos dados das linguagens da orientação a 
objetos, sem exigir uma linguagem de consulta relacional como interface de banco de 
dados. (2006, p. 239)
O modelo é utilizado com maior frequência por algumas áreas determinadas, como 
a espacial e a física, que exigem manipulação de dados de maior complexidade. Para uso 
comercial, o modelo orientado a objetos ainda é pouco difundido. 
Os objetos são compostos por dois elementos: atributos (dados) e métodos (instruções 
do que fazer com os dados). Quando existem objetos que possuem os mesmos métodos e 
atributos com nome e domínio iguais, estes são agrupados, constituindo assim as classes.
As principais características do paradigma orientado a objetos são aplicadas neste 
modelo, apesar de haver algumas limitações. O encapsulamento é uma das características 
que definem o paradigma e consiste em permitir ou ocultar a visualização de elementos de 
uma classe para outra. 
No modelo de banco de dados orientado a objetos, esse conceito não se aplica em 
sua totalidade. Isso devido à necessidade de, ao se realizar uma consulta a uma tabela, ser 
preciso conhecer todos seus atributos. Além disso, em alguns casos, a consulta exige que 
atributos de outras tabelas também precisem ser acessados, impossibilitando, assim, a 
ocultação de informações. Por outro lado, nas atividades que envolvem apenas o compor-
tamento dos objetos como inserção ou exclusão, os bancos de dados orientados a objetos 
podem ocultar os detalhes da implementação para usuários externos.
37Administração de Banco de Dados
A herança também pode ser implementada no modelo de banco orientado a objetos. 
É possível gerar uma hierarquia de classes, na qual a de mais alto nível (superclasse) possui 
métodos e atributos que serão herdadas pelas classes de nível mais baixo (subclasse). Isso 
oferece aos bancos uma das grandes vantagens da orientação a objetos que é a reutiliza-
ção, na qual as subclasses utilizam a mesma implementação de métodos da superclasse, 
exceto em casos nos quais uma delas necessita de implementação distinta.
A figura a seguir apresenta um exemplo de herança:
Exemplo de herança
Conta
– numero : inteiro
– nome_cliente : texto
– saldo : real
+ sacar() : void
+ depositar() : void
+ custoManutencao() : void
Corrente Poupança
+ custoManutencao() : void + custoManutencao() : void+ custoManutencao() : void
A figura acima é composta por uma superclasse (Conta) que possui os atributos 
numero, nome_cliente e saldo e três métodos: sacar, depositar e custoManutencao. Além 
disso, apresenta duas subclasses (Corrente e Poupança) que, por herdarem as caracterís-
ticas da superclasse, não precisam implementar novamente os atributos e métodos. O 
método custoManutencao é o único que precisou ser reescrito, pois o calculo para esse 
custo é distinto entre as contas.
Os bancos de dados orientados a objetos, devido à capacidade de armazenamento 
de dados mais complexos e do sistema de reutilização de objetos, é bastante utilizado para 
armazenamento multimídia e hipertexto. Como desvantagens desse tipo de modelo, pode-
-se citar o alto custo de implementação e o receio das empresas de fazer a migração para 
um novo sistema depois de já terem investido em um outro formato.
Alguns SGBD que trabalham com a orientação a objetos são: Objetivity/DB, CACHÉ, 
VERSANT, dentre outros.
©
 D
TC
O
M
Administração de Banco de Dados38
1.3.4. Objeto relacional
O modelo objeto relacional combina as características do modelo relacional com o 
modelo orientado a objetos. Nele os objetos são modelados em tabelas, utilizando assim 
os dois principais elementos que compõem cada modelo. Apesar dos dados serem armaze-
nados em tabelas é possível utilizar todos os conceitos que envolvem a orientação a obje-
tos, como o encapsulamento e a herança.
As classes podem ser desenvolvidas como um novo tipo que é suportado pelo modelo 
relacional. Por exemplo, dada a classe Conta a seguir:
Conta
– numero : inteiro
– saldo : real
É possível desenvolver o seguinte esquema:
Cliente (Conta_Corrente: Conta, Nome: texto) 
Sendo assim, no modelo relacional teríamos:
Tabela Cliente
Conta_Corrente Nome
100
5000.00
Maria
200
3200.00
José
A grande vantagem deste modelo em relação ao modelo relacional é que aqui é pos-
sível a utilização de dados complexos, como podemos observar na coluna Conta_Corrente, 
que possui dois valores (numero, saldo) para cada linha. Já no modelo relacional tradicio-
nal, não é permitido o uso de atributos multivalorados.
Oracle, DB2 e PostgreSQL, são alguns dos SGBD objeto relacional que é possível 
encontrar no mercado.
39Administração de Banco de Dados
1.4. Modelo NoSQL
Com o aumento do uso de aplicações que exigem uma grande quantidade de dados 
que não estejam por completo centralizados, sentiu-se a necessidade de um modelo de 
banco de dados que possuísse melhor flexibilidade e escalabilidade. Surgiu então o modelo 
NoSQL, Not Only SQL, em tradução literal: Não somente SQL. Sua ideia inicial foi pro-
posta por comunidades de software livre e empresas de pequeno porte.
Esse novo modelo apresenta características que rebatem os principais conceitos do 
modelo relacional, por isso é chamado também de modelo não relacional. Sempre que há 
aumentos significativos no volume de dados a ser processado por um banco, há a necessi-
dade de aumento de escala do mesmo, além de melhora no desempenho. O modelo rela-
cional trabalha com um tipo de escalabilidade chamado de vertical, ou seja, sempre que 
surge esta necessidade, aumenta-se o poder de processamento e a memória das máquinas 
existentes. Já o modelo NoSQL, trabalha com a escalabilidade vertical, na qual utiliza-se 
a adição de novas máquinas para solucionar o problema. A escalabilidade vertical tende a 
possuir menor custo e maior rapidez de implantação.
O modelo relacional prezapela não redundância e a consistência dos dados no banco. 
Para garantir essas características, utiliza diversas regras de integridade e de normalização 
dos dados. Esta é uma das grandes vantagens do modelo, mas tratando-se de um volume 
maior de dados, para o qual seja necessário o relacionamento de várias tabelas, existirá 
uma queda na produtividade do banco. 
O NoSQL preza por um desempenho mais rápido, no qual não haja a necessidade de 
um gasto alto de desempenho do banco para realizar consultas simples. A consistência no 
NoSQL é eventual. Quando há a possibilidade, o modelo opta por disponibilidade em troca 
de inconsistências temporárias.
Existem alguns tipos de modelo NoSQL, dentre eles destacam-se os modelos orien-
tado a documento, chave-valor, orientado a coluna e orientado a grafo.
1.4.1. Orientado a documento
No modelo orientado a documento não existem tabelas nem relacionamentos, todos 
os dados são salvos em uma coleção de documentos. Os dados são armazenados em pares, 
com um identificador para cada valor. Além disso, os próprios documentos também têm 
um identificador, o que o torna único em cada base.
Administraç�o de Banco de Dados40
O modelo oferece maior flexibilidade já que, diferentemente do modelo relacional, 
que exige um sistema rígido, este modelo não possui essa rigidez, tornando a alteração da 
estrutura do documento uma tarefa que não causará problemas ao banco de dados.
A figura a seguir é um exemplo de um documento criado no modelo:
Exemplo de documento (Ferramenta Fauxton)
O documento foi criado com quatro campos e seus respectivos valores. O campo “_
id” é gerado automaticamente pela própria ferramenta e tem como objetivo identificar 
o documento na coleção deles existente no banco. A ferramenta utilizada na geração do 
documento foi a Fauxton que é uma interface para o banco CouchDB.
Dica
O CouchDB é um banco NoSQL de código aberto gerenciado pela Apache Soft-
ware Foundation para trabalhar com o modelo orientado a documento. Existem versões do 
banco para Windows, Linux e MacOS. É possível conhecer detalhes do projeto acessando o 
site CouchDB.
Além do CouchDB, existem outros bancos que utilizam o modelo, como MongoDB e Riak.
1.4.2. Valor-c�ave
O modelo chave-valor é o mais simples e um dos modelos NoSQL mais utilizados. Na 
verdade, os outros modelos são derivados dele. Este modelo consiste em associar cada valor 
a uma chave. Cada item do banco é exatamente essa combinação do valor com sua chave. A 
recuperação dos dados apenas poderá ser acessada por meio da sua chave especifi ca.
Esse modelo também é livre de esquema, podendo assim realizar a adição de novos 
campos, por exemplo, em tempo de execução, sem ocasionar problemas ao banco de 
41Administração de Banco de Dados
dados. Uma das vantagens do modelo chave-valor, é a rapidez no acesso aos dados, além 
dele suportar uma grande quantidade de dados.
A tabela a seguir representa a organização dos dados no modelo chave-valor.
Chave Valor
nome_cliente_100 Maria
saldo_cliente_100 5000.00
nome_cliente_200 José
saldo_cliente_200 3200.00
Como demostra a figura acima, o modelo chave-valor consiste basicamente em uma 
tabela com apenas duas colunas: uma referente à chave e outra ao seu respectivo valor. 
Diferente das tabelas do modelo relacional, as colunas neste modelo não possuem domí-
nio. Nota-se que o valor da primeira linha é um texto (Maria), já o da segunda linha é um 
valor real (5000.00).
Alguns exemplos de banco que implementam esse modelo são o Redis, Riak e 
DynamoDB.
1.4.3. Orientado a coluna
O modelo orientado a coluna apresenta uma complexidade superior ao modelo cha-
ve-valor e possui elementos similares ao modelo relacional. Nesse modelo, os dados são 
armazenados utilizando uma tripla que consiste em uma linha, uma coluna e o timestamp 
que tem a função de auxiliar no controle de versões.
Cada coluna é um índice no banco e colunas que armazenam o mesmo tipo de dados 
são agrupadas em famílias. É possível assim acessar dados de forma isolada.
A figura a seguir exemplifica a organização de dados no modelo orientado a coluna:
Administração de Banco de Dados42
Exemplo da organização dos dados no modelo orientado a coluna
ID1
ID2
dados_cadastrais
nome
numero
numero
saldo
saldo
emprestimo
conta_corrente
conta_poupanca
idade endereco complemento
Maria
José
32
27
Rua das Flores
Avenida Caldas Ap. 201
100
200
200
5000.00
3200.00
1500.00
10000.00
Fonte: MARQUESONE, 2016. (Adaptado).
A figura acima apresenta uma estrutura que possui três famílias de colunas: dados_
cadastrais, conta_corrente, conta_poupança. Cada uma dessas famílias tem um conjunto de 
colunas com dados que faz referência a elas. Pode-se perceber no modelo que é possível dis-
tinguir entre o número de colunas de um registro para outro. É o que acontece, por exem-
plo, na família de colunas dados_cadastrais, na qual ID2 possui 4 colunas e o ID1 apenas 3.
Alguns exemplos de bancos que implementam o modelo são: BigTable, Cassandra e 
HBase.
1.4.4. Orientado a grafo
Este modelo baseia-se na teoria dos grafos e ao invés de linhas e colunas utiliza vér-
tices e arestas para realizar o armazenamento e relacionamento dos dados do banco. Cada 
vértice (nó) representa uma entidade e suas informações e as arestas representam os rela-
cionamentos. Este tipo de banco é utilizado quando há ligações fortes entre os dados, 
como em aplicações para traçar menor rota, redes sociais e árvores genealógicas.
A figura a seguir representa como os dados são organizados em um banco orientado 
a grafo:
Maria
Bruna Felipe
Mãe Mãe
Marcos
Mãe
Pai
Pai
Pai
José Alba João
Casada
com
Casada
com
Casada
comPrimo
A figura acima represente uma árvore genealógica. Os nós possuem as entidades 
envolvidas e as arestas os relacionamentos existentes entre eles, bem como a sua descrição.
Marquesone (2016) comenta que apesar de outros modelos, inclusive o relacional, 
possuir a capacidade de traçar o relacionamento entre os dados, tratando-se de um grande 
emaranhado de dados, as consultas se tornariam extremamente complexas, causando 
assim uma grande perda de desempenho.
Alguns dos bancos que utilizam o modelo são: Neo4J, HyperGraphDB e AllegroGraph.
Pausa para refletir 
Agora que conhecemos diferentes modelos para banco de dados, qual deles é o melhor?
Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa, 
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.
Agora é a hora de recapitular tudo o que você aprendeu nesse capítulo! Elabore uma síntese 
destacando as principais ideias abordadas ao longo do capítulo. Ao produzir sua síntese con-
sidere as leituras básicas e complementares realizadas.
Recapitulando
Neste capítulo pudemos conhecer os diferentes tipos de sistemas de bancos de dados 
existentes no mercado, bem como suas características e estruturas. O uso de um banco 
que mantenha a integridade dos dados e garanta a segurança na transação dos mesmos, 
é de fundamental importância para as empresas, já que a informação pode oferecer um 
grande diferencial competitivo no mercado. Além disso, com a era digital, a quantidade de 
dados que são armazenados em meio eletrônico aumentou consideravelmente tornando o 
uso de sistemas gerenciadores de bancos de dados ainda mais justificado.
Durante o capítulo foram apresentadas as diferentes estruturas de armazenamento de 
dados nos bancos como tabelas, objetos e grafos. Apesar de existirem todos esses sistemas 
gerenciadores de banco de dados, não é possível definir qual deles é o melhor a ser utili-
zado. Isso por que o uso de cada um deles depende exclusivamente do tipo de negócio em 
que se deseja trabalhar. Para o uso de dados que não exijam um alto nível de complexidade, 
por exemplo, é possível utilizar o modelo relacional sem perda alguma de produtividade, 
caso contráriorecomenda-se utilizar o modelo orientado a objetos ou o modelo NoSQL.
Referências
BEAL, A. Gestão Estratégica da Informação. São Paulo: Atlas S.A., 2004.
CouchDB Relax. Disponivel em: <couchdb.apache.org/>. Acesso em: 01 jun. 2018.
ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados. 4. ed. São Paulo: Pearson 
Addison Wesley, 2005.
MARQUESONE, R. Big Data: Técnicas e tecnologias para extração de valor dos dados. 
[S.l.]: Casa do Código, 2016.
SILBERSCHATZ, A. Sistemas de Bancos de Dados. 5. ed. São Paulo: Makron, 2006.
47Administração de Banco de Dados
OBJETIVOS DO CAPÍTULO
• Entender como elaborar comandos básicos e avançados em SQL.
CAPÍTULO 2
Structured Query Language (SQL)
Márcio dos Santos 
TÓPICOS DE ESTUDO
1 Organização 2 Recursos
• Linguagem de Definição de Dados 
(DDL).
• Linguagem de Manipulação de Dados 
(DML).
• Stored Procedures
• Functions
• Triggers
Administração de Banco de Dados48
Contextualizando o cenário
Vivemos, indiscutivelmente, na era da informação, na qual a composição e detenção dos 
dados valem mais que dinheiro em espécie. Ter os dados organizados de maneira eficiente 
e sem redundância auxilia a qualquer empresa na tomada de decisões cruciais. Com base 
nisso, imagine o seguinte cenário fictício: um hipermercado precisa organizar toda a sua 
estrutura dentro de um sistema confiável de Banco de dados. A empresa gostaria de imple-
mentar um cadastro de fornecedores, funcionários, clientes, produtos e frota de veículos. 
Qual a estrutura de tabelas, triggers, procedures e funções que seria mais adequada 
para a implementação deste banco de dados?
49Administração de Banco de Dados
2.1. Organização
Compreender os critérios de armazenamento de uma informação num banco de 
dados é o fator determinante para um completo domínio do assunto, bem como para evi-
tar redundâncias e inconsistências que podem repercutir em tomadas de decisões errô-
neas, baseadas em informações que não representam a realidade. Antes que possamos 
iniciar nossa jornada por este caminho, é importante que tenhamos como princípio básico 
o conceito de que abordaremos a temática baseada em Banco de Dados Relacionais, que 
são atualmente os modelos dominantes no mercado.
Veremos neste capítulo algumas estruturas que compõem tanto a arquitetura física 
de um Banco de Dados, como também as maneiras de se manipular cada registro através 
da linguagem SQL (Structured Query Language) e suas sublinguagens atreladas. Por fim, 
veremos ainda alguns recursos que irão automatizar tarefas e criar procedimentos de exe-
cução com linguagens de programação embutidas no corpo do SQL.
Os exemplos utilizados neste capítulo serão voltados a aplicações em Bancos MySQL 
em sua versão 5.0 ou superior. Considere um Banco de Dados como uma estrutura ou con-
junto de dados que possuem relação entre si, pois um dado isolado dificilmente conseguirá 
compor uma informação se não possuir elos com outros dados. 
Desta forma, existe uma relação entre os dados armazenados, o que resulta no 
Modelo do Banco de Dados que estamos tratando: relacional. Bancos relacionais são com-
postos por conjuntos de tabelas e as operações que as utilizam são realizadas por lingua-
gens específicas (MACHADO, 2008). Duas dessas linguagens veremos logo a seguir.
2.1.1. Linguagem de Definição de Dados (DDL)
O SQL é a linguagem de consultas utilizada pela maioria dos bancos de dados, em 
geral, os do tipo relacional. A sintaxe de códigos SQL é consideravelmente simples de se 
compreender e mesmo pessoas não técnicas conseguiriam interpretar os conceitos básicos 
da linguagem aplicando apenas uma base teórica de Inglês.
O SQL tem algumas divisões em sua estrutura, que são linguagens atreladas ao pró-
prio SQL. Isso não significa que as linguagens que veremos doravante sejam diversas ao 
próprio SQL, pelo contrário, elas são SQL em si, mas pertencem a categorias distintas de 
acordo com a ação que executam sobre o Banco de Dados. A primeira linguagem que vere-
mos é a DDL, que significa Data Definition Language (Linguagem de Definição de Dados).
Administração de Banco de Dados50
Dentro do escopo da DDL estão atrelados os eventos que alteram a estrutura do 
Banco de Dados como tabelas, usuários, triggers, procedures, etc. Em nada difere uma 
estrutura DDL de outra quanto à aplicabilidade das sintaxes senão pela própria ação exe-
cutada, assim compreenda que quando você estiver desenvolvendo um comando DDL, 
estará, de fato, escrevendo um código SQL, mas com o intuito de manipular a estrutura 
do Banco de Dados com um todo, e não apenas com o intuito de manipular as informações 
contidas em tabelas do banco de dados.
Com DDL é possível criar, alterar ou remover estruturas. Para cada uma dessas 
ações existe uma sintaxe específica em SQL:
• CREATE: cria estruturas. 
• ALTER: altera estruturas. 
• DROP: remove estruturas. 
Um pouco mais adiante, ainda neste mesmo capítulo, discutiremos a respeito da dife-
rença entre a DDL e a DML. Embora sejam escritas em código SQL, ambas atuam de dife-
rentes formas dentro de um Banco de Dados.
O comando CREATE é utilizado para criar novas estruturas. Com ele é possível criar 
tabelas, usuários, triggers, procedures, views e functions. Vejamos como funciona a cria-
ção de uma tabela em um Banco de Dados. Para fins de teste, chamaremos esta tabela 
de ALUNO e ela terá 4 campos: id, nome, matricula, email, respeitando algumas regras 
quanto ao tipo de dado aceito. 
1 CREATE TABLE aluno(
2 id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
3 nome VARCHAR(100) NOT NULL,
4 matricula CHAR(10) NOT NULL,
5 email VARCHAR(50) NOT NULL
6 );
Da linha 2 à linha 5 criamos os campos que esta tabela terá. Cada campo tem sua 
especificação, sejam elas restrições de integridade ou restrições de domínio. Restrições de 
integridade referem-se à interação de uma tabela com outras, ou ainda com a forma como 
um determinado campo será visto pelos demais daquela mesma tabela. Restrições de 
domínio referem-se ao campo em si como a exigência para que um campo não seja vazio, 
por exemplo.
51Administração de Banco de Dados
Na linha 6, temos o encerramento do comando. O ponto e vírgula disposto ao final 
não é obrigatório. Sua colocação é exigida apenas quando, após a execução deste bloco de 
código, outro bloco venha a ser executado em seguida.
Vejamos algumas restrições utilizadas neste trecho de código:
• NOT NULL: restrição de domínio. Aponta que um campo não pode ficar vazio;
• PRIMARY KEY: restrição de Integridade. Aponta que aquela coluna é a chave pri-
mária de uma tabela;
• AUTO_INCREMENT: restrição de domínio/integridade. Aponta que aquele campo 
irá incrementar-se a cada nova inserção no banco;
• INT, VARCHAR, CHAR: restrição de domínio. Aponta o tipo de dado que será aceito 
num determinado campo (INT para inteiros, VARCHAR para Strings, CHAR para 
caracteres isolados). Em alguns casos será necessário apontar o tamanho do campo, 
por exemplo: VARCHAR(255), que aceitaria uma string de até 255 caracteres.
Internalize para si que o comando CREATE (MYSQL, 2018a; 2018b; 2018c) não é limi-
tado a criação apenas de tabelas (como no exemplo acima). Ele é usado para criar N estru-
turas dentro de um Banco de Dados. 
A seguir vamos atentar a alguns detalhes deste trecho de código.
Dica
Ao realizar operações DDL, você precisará respeitar o mesmo conceito de regras 
de variáveis. Toda variável não pode:
• começar com números;
• conter caracteres especiais;
• ter espaços.
Procure seguir essas mesmas regras para os comandos DDL para evitar erros de execução 
dos comandos.
Na linha 1, temos o comando CREATE, que é sempre seguido da ação que queremos 
criar no banco. Neste caso, uma tabela. Em seguida, temos o nome da tabela. Embora os 
comandos tenham sido escritos em maiúsculo, o SQL não é case sensitive, ou seja, não 
diferencia maiúsculas de minúsculas, entretanto, esta regra aplica-se aos elementos da 
linguagem e não aosvalores que inserimos, ou seja, se o nome da tabela for escrito em 
maiúsculas, ele será mantido em maiúsculas dentro do banco; se um campo for escrito no 
formato CamelCase, assim ele ficará.
Administração de Banco de Dados52
Mais exemplos de uso do comando CREATE:
CREATE DATABASE meuBancoDeDados
// Cria um Banco de Dados
CREATE USER ‘usuario@meuBancoDeDados’ IDENTIFIED BY ‘senha’
// Cria um usuário chamado “usuario” no banco de dados “meuBancoDeDados”, com a senha 
“senha”
CREATE TRIGGER nomeDaTrigger
BEFORE INSERT ON aluno
FOR EACH ROW
BEGIN
 INSERT INTO teste(campo)VALUES(‘valor’)
END;
Esse comando cria um Trigger (MYSQL, 2018c) que será ativado sempre que uma 
nova tentativa de inserção ocorrer na tabela “ALUNO”. Veremos detalhes sobre os triggers 
mais adiante.
Pausa para refletir 
Existem alguns tipos de dados que podem ser utilizados nos Banco de Dados, como VARCHAR, 
INT, CHAR, seja para a armazenagem de conteúdo ou para facilitar na administração do banco. 
Pesquise na bibliografia recomendada outros tipos usados nos Bancos de Dados Relacionais.
O comando DDL ALTER (MYSQL, 2018d) permite alterar alguma estrutura já exis-
tente no Banco de Dados. Observe que quando falamos sobre estrutura não estamos nos 
referindo a dados salvos, ou seja, não tratamos sobre o conjunto das informações inseridas 
e sim sobre a estrutura que compõe o banco, independentemente dele estar vazio ou não.
Alguns elementos que podem ser alterados: Tabelas, Triggers, Views, Procedures, 
Usuários. Vejamos um exemplo de estrutura para alteração da mesma tabela “ALUNO”, 
criada anteriormente.
53Administração de Banco de Dados
ALTER TABLE aluno [AÇÃO DESEJADA] [LOCAL DE APLICAÇÃO]
Na prática:
ALTER TABLE aluno DROP COLUMN email
Este exemplo alteraria a tabela aluno apagando a coluna email. Este é apenas um 
exemplo, mas é possível realizar alterações diversas na estrutura da tabela: adicionar ou 
remover chaves primárias, apontar recursos de auto incremento, bem como modificar res-
trições de domínio ou de integridade.
Vinculados ao comando ALTER estão as funções DROP e ADD. A utilização do DROP 
é voltada para a exclusão de parte da estrutura a ser alterada. Já o comando ADD é respon-
sável por adicionar algo à estrutura. 
ALTER TABLE aluno ADD(email VARCHAR(50))
O exemplo acima é uma forma de reescrever o comando, mas com uma nova funcio-
nalidade que altera a tabela aluno adicionando um campo chamado email, do tipo Varchar, 
com capacidade de até 50 caracteres.
Por fim, temos o comando DROP (MYSQL, 2018e), responsável por remover estrutu-
ras ou elementos de estruturas de um Banco de Dados. O comando DROP tem a seguinte 
sintaxe:
DROP [TIPO DE ESTRUTURA][NOME DA ESTRUTURA]
Na prática:
DROP TABLE aluno
Administração de Banco de Dados54
Embora sua ação seja bastante enfática, a sintaxe de remoção é bastante simples. Adi-
cionalmente, o comando DROP pode ser utilizado dentro do comando ALTER para remover 
colunas, remover chaves primárias ou ainda remover relações entre tabelas. O comando DROP 
remove estruturas do Banco. Foi utilizado um exemplo de remoção de tabelas, mas o mesmo 
exemplo pode ser usado para remoção de um usuário, de um trigger, de uma view etc.
Assista
Assista a vídeos sobre Banco de Dados disponíveis no canal da Universidade Virtual 
de São Paulo para compreender de forma mais profunda os conceitos do capítulo. A Aula 1, por 
exemplo, chama-se “Visão geral sobre banco de dados e motivação” (UNIVESP, 2017). 
De forma similar ao comando ALTER, o comando DROP não deve ser confundido com 
a remoção de registros do banco de dados. O DROP deve ser utilizado apenas quando seu 
intuito for manipular elementos da estrutura do Banco, como uma tabela, uma function ou 
itens similares. A remoção de dados em si (registros), é feita através da linguagem DML, 
que será analisada a seguir.
A essência de conhecer o conjunto de comandos pertencentes a cada linguagem está 
exatamente em discernir quais os comandos atrelados a ela, evitando a escrita de coman-
dos inválidos. 
2.1.2. Linguagem de Manipulação de Dados (DML)
Agora que já vimos os conceitos básicos de DDL, fica mais fácil introduzir a DML 
(Data Manipulation Language - Linguagem de Manipulação de Dados). Ao contrário da 
DDL, a DML não lida com a estrutura que compõe o banco, mas sim com os dados inseri-
dos. De forma similar, existe também um conjunto de comandos que são utilizados especi-
ficamente para manipulação desses registros:
• INSERT: insere dados no Banco;
• SELECT: realiza consulta de dados gravados no Banco;
• UPDATE: atualiza dados salvos no Banco;
• DELETE: apaga dados salvos no Banco.
Vamos explanar cada um dos comandos acima, conhecendo-os e entendendo a sua 
estrutura.
55Administração de Banco de Dados
Curiosidade
O comando SELECT, de acordo com algumas bibliografi as, pode pertencer tanto 
à DML quanto à DQL (Data Query Language – Linguagem de Consulta de Dados), assim, será 
comum você encontrar autores que irão atrelar o comando SELECT às duas linguagens.
Sobre o comando INSERT (MYSQL, 2018f) vamos tomar como base a tabela aluno
criada anteriormente, populando-a. Não esqueça que só serão aceitos dados do mesmo 
tipo que foram declarados na estrutura da tabela, ou seja, se a um campo foi atribuída a 
restrição de domínio INTEIRO, ele só poderá receber dados numéricos inteiros, não acei-
tando valores decimais ou outros caracteres. Esta mesma regra vale para os demais tipos 
de dados (strings, chars, booleans, blobs, date, etc).
A ordem da sintaxe é a seguinte:
INSERT INTO[nome_da_tabela] [campos] VALUES [valores]
Na prática:
DROP TABLE aluno
O nome dos campos é um item opcional na inserção. Ele só se torna obrigatório caso 
os valores a serem inseridos sejam colocados fora de ordem, por exemplo: sabemos que a 
ordem dos campos é exatamente a seguinte: id, nome, matricula, email. Caso algum dado 
seja inserido fora da ordem correta, o valor será alocado num campo incorreto do Banco de 
Dados. Além disso, pode ocorrer conflito de restrição de domínio no caso de uma inserção 
que seja contrária a este princípio.
Desta forma, recomenda-se que os nomes dos campos sejam listados como uma maneira 
de garantir que cada registro será alocado corretamente no campo que lhe condiz. Observe 
que o primeiro campo, id, foi preenchido, todavia este preenchimento é desnecessário, consi-
derando que na criação da tabela estipulamos que o referido campo deveria ser do tipo AUTO 
INCREMENTO, ou seja, ele seria incrementado de forma automática a cada nova inserção.
Este campo, embora não seja obrigatório, é importante para que cada registro possa 
ter um identificador único atrelado a ele. Geralmente atribuímos a função de autoincre-
mento à chave primária da tabela. Um outro campo que poderia a ser chave primária seria 
o campo de matrícula, pois cada matrícula é única dentro do sistema.
Administração de Banco de Dados56
Podemos notar que temos alguns campos que são únicos nesta tabela de alunos, ou 
seja, não existe nenhuma possibilidade desses campos se repetirem. Tais campos são o id, 
matricula e email.
Quando temos um conjunto de campos que, juntos, identificam de forma única cada 
registro, atribuímos a este conjunto o nome de chaves candidatas.
Curiosidade
Todo Banco de Dados Relacional é composto por tabelas que contém linhas e 
colunas que se unem formando registros. As tabelas também são chamadas de Relações, os 
registros também podem ser chamados de tuplas e as colunas de atributos.
As chaves candidatas são apenas conceituais, ou seja, não há a implementação em 
linha de comando ou com apontamento no SQL. As chaves candidatas provém a possibi-
lidade de identificar de maneira unívoca um determinado registro dentre todos os demais 
alocados no Banco de Dados, mesmo que estejam em tabelas distintas que se relacionem 
entre si. Vale ressaltar que o principal conceito de um banco de dados relacional é justa-
mente compor um conjuntode informações relacionadas (BEAULIEU, 2010), por n tabelas.
O relacionamento para compor uma informação não é uma obrigatoriedade, princi-
palmente quando tratamos de informações objetivas e cujo conteúdo possa ser obtido em 
apenas uma tabela, mas o cenário de relação de tabelas é o mais comum quando tratamos 
de consultas mais elaboradas.
O comando SELECT (MYSQL, 2018g) é utilizado para realizar consultas no Banco de 
Dados. A sintaxe básica do comando SELECT é a seguinte:
SELECT [ATRIBUTOS OU FUNÇÕES] FROM [TABELA] [CLÁUSULAS RESTRITIVAS]
Na prática, utilizamos a mesma tabela já desenvolvida anteriormente:
SELECT * FROM aluno WHERE id = 1
No exemplo citado acima, podemos observar que após a palavra reservada SELECT, 
existe um asterisco. O asterisco (*) na computação, em geral, simboliza tudo ou todos, 
salvo exceções pontuais em que sua inserção tem cunho matemático, representando o 
símbolo de multiplicação. Assim, o comando acima descreve a seguinte consulta: busque 
57Administração de Banco de Dados
todos os registros da (from) tabela aluno onde (where) o id (campo) seja igual a 1. Como já 
mencionado no início deste capítulo, o conhecimento básico de Inglês fará com que você, 
intuitivamente, consiga compreender os comandos SQL sem muitas dificuldades, mesmo 
que não domine totalmente a linguagem. Isso te auxiliará no aprendizado.
No exemplo acima todos os campos (id, nome, matricula, email) serão exibidos. No 
lugar do asterisco, podemos apontar um campo específico que desejamos que seja exibido. 
O primeiro exemplo exibirá apenas o nome do aluno cujo id seja 1:
SELECT nome FROM aluno WHERE id = 1;
SELECT nome, email FROM aluno WHERE id = 1
O terceiro exemplo exibirá a matrícula do aluno, cujo id seja 1, mas o título da coluna 
passará a ser MAT:
SELECT matricula AS MAT FROM aluno WHERE id = 1
O comando AS permite criar um Alias para um determinado campo. Funcionaria como 
um apelido temporário, que é atribuído a uma coluna da tabela para que a compreensão dos 
campos fique mais clara durante a exibição. Em nosso exemplo estamos utilizando nomes 
curtos e bastante intuitivos (id, nome, matricula, email), mas em casos reais do dia a dia, nem 
sempre isso é possível, forçando o Administrador de Banco de Dados a criar nomes de cam-
pos complexos, grandes e às vezes com abreviaturas que dificultariam a compreensão dos 
resultados exibidos por alguém que não conheça a estrutura do Banco de Dados.
Da mesma forma, é possível apelidar tabelas, de forma que seja possível utilizar seus 
apelidos posteriormente dentro das cláusulas de restrição:
Logo após o nome da tabela é inserido o apelido que ela terá.
SELECT * FROM aluno A WHERE id = 1
A mesma lógica aplicada aos campos pode ser utilizada quanto às tabelas, possibili-
tando a consulta de registro em mais de uma tabela ao mesmo tempo. De acordo com o 
exemplo abaixo serão exibidos apenas os nomes do aluno e professor cujo id seja igual a 1: 
Administração de Banco de Dados58
SELECT nome FROM aluno A, professor B WHERE A.id = 1 AND B.id = 30
Veja que para referenciar a tabela foi utilizado o seu apelido, um ponto e o campo de 
restrição (A.id e B.id). Caso o apelido não tivesse sido atribuído às tabelas, seria necessário 
referenciá-las pelo nome e isso poderia resultar em um código maior e de difícil compreen-
são, dependendo do tamanho do nome das tabelas envolvidas.
As cláusulas restritivas (ou de restrição) que comentamos nos parágrafos anteriores 
podem ser utilizadas tanto em consultas SQL como na exclusão ou alteração de registros, 
como veremos mais adiante. Essas cláusulas, como o próprio nome já diz, restringem os 
registros a um número específico. Existem diversas cláusulas de restrição. Veremos algu-
mas delas:
• WHERE: a mais conhecida. Especifica uma característica do resultado a ser exi-
bido, excluído ou editado. É limitado a apenas um uso por comando SQL;
• AND: só pode ser utilizada posposta à cláusula WHERE. Pode ser repetida quantas 
vezes forem necessárias. Atente ao detalhe: a cláusula AND colocará uma restrição 
aditiva, ou seja, será necessário que o resultado obtido atenda à restrição WHERE 
e à outra restrição proposta dentro do AND.
• OR: só pode ser utilizada posposta à cláusula WHERE e pode ser repetida quan-
tas vezes forem necessárias. Opostamente à cláusula AND, a cláusula OR tem a 
função disjuntiva, ou seja, permite que o resultado obtido atenda tanto à cláusula 
WHERE quanto à cláusula OR, ou a ambas.
• XOR: segue os mesmos preceitos de colocação do AND e do OR. A diferença está 
em sua aplicação. O “X” representa a palavra Exclusive. Isso faz com que o resul-
tado obtido seja OU da cláusula WHERE OU da cláusula XOR. Assim, se o resul-
tado da consulta, da edição ou da exclusão atender às duas cláusulas, a execução 
não ocorrerá, visto que o resultado de saída será falso.
Assista
Assista à aula do canal UNIVESP (2016) sobre o tema XOR. O assunto é abordado 
de forma bastante efi ciente para compreensão dos conceitos. O vídeo é intitulado Álgebra de 
chaveamento e minimização de funções algébricas e o tema XOR é introduzido a partir dos 22’.
59Administração de Banco de Dados
Na bibliografia recomendada você poderá ver todas as cláusulas restritivas em SQL. 
Aqui abordamos apenas as mais comuns para que você compreenda o assunto e esteja 
apto a seguir com seus estudos tendo esta base conceitual.
É importante que você compreenda que existe uma sequência de uso das cláusulas 
de restrição caso seja necessário utilizar várias. Partindo do pressuposto de que numa con-
sulta SQL você precise utilizar as cláusulas WHERE, AND, OR, LIMIT, ORDER BY, GROUP 
BY, a ordem deveria ser:
• primeiro a cláusula WHERE;
• seguida das cláusulas AND ou OR ou XOR, independentemente da ordem;
• seguidas da cláusula GROUP BY;
• seguida da cláusula ORDER BY;
• finalizando com a cláusula LIMIT.
Em qualquer situação a cláusula LIMIT será sempre a última.
Ainda, como um adendo, a execução de um comando SQL respeita os princípios com-
putacionais, que por sua vez respeitam os princípios matemáticos. Isso significa que é pos-
sível agrupar a execução de determinados comandos através de parênteses:
1 SELECT * FROM aluno
2 WHERE aluno_id > 10
3 AND (aluno_nome LIKE ‘%A’ OR aluno_nome LIKE ‘%O’)
A consulta SQL acima, ao chegar na linha 3, acessaria o conteúdo disposto dentro dos 
parênteses, executaria a operação e então traria o resultado para fora dos parênteses, para 
ser processado pela cláusula AND externa.
Diferentemente da matemática, onde a existência de subgrupos é apontada pelo uso 
de chaves, colchetes e parênteses, na programação, de forma geral, inclusive em SQL, é 
permitido apenas o uso de parênteses dentro de parênteses, de forma infinita, para marcar 
os subgrupos existentes:
1 SELECT * FROM aluno
2 WHERE aluno_id > 10
3 AND(aluno_idade = 18 OR(aluno_nome LIKE ‘%A’ OR aluno_nome LIKE ‘%O’))
Administração de Banco de Dados60
Veja que existe um grupo dentro de outro grupo na linha 3 e este subgrupo foi mar-
cado apenas com a inserção de um parênteses dentro de outro parênteses.
A mesma regra matemática será respeitada e executada neste caso: primeiro o 
grupo mais interno é processado, trazendo o resultado do processamento para fora. Este 
resultado é novamente processado no grupo externo, trazendo um novo resultado para a 
cláusula principal. Lembre-se que não há limite para a existência de grupos e subgrupos, 
todavia o processamento poderá ter desempenho inferior.
Seguindo com a análise de comandos, o UPDATE (MYSQL, 2018h) é utilizado para 
atualizar algum (ou vários) registros no Banco de Dados. O update possui a seguinte sintaxe:
UPDATE [TABELA] SET [CAMPO] = NOVO_VALOR
Na prática:
UPDATE aluno SET nome = “João da Silva Santos”
Embora o comando acima esteja correto, ele irá atualizar todos os registros do banco 
de dados, modificando o nome dos alunos para “João da Silva Santos”. Isso será realizado 
devidoà ausência de uma cláusula de restrição, que limitará os registros que serão afetados:
UPDATE aluno SET nome = “João da Silva Santos” WHERE nome = “João da Silva”
Com este incremento limitamos as alterações apenas ao grupo de usuários que se 
chamarem João da Silva. É possível utilizar várias outras formas de restrição, inclusive 
pelo número da matrícula, pelo id, pelo e-mail e pela combinação de dois ou mais campos. 
Caberá ao administrador do banco de dados analisar qual a situação e o escopo mais ade-
quado a ser aplicado.
O comando DELETE é utilizado para realizar a exclusão de registros de um banco 
de dados. Diferentemente do comando DDL DROP, que afeta a estrutura do banco, o 
comando DELETE (MYSQL, 2018i) afeta os registros gravados. Em suma, comandos DML 
só são utilizados quando existem registros no banco de dados.
A sintaxe do DELETE é tão simples quanto a do DROP, porém é recomendado o uso 
de cláusulas de restrição para evitar a exclusão de conteúdos de forma desordenada e dife-
rente do esperado:
61Administração de Banco de Dados
DELETE FROM [TABELA][CLÁUSULAS RESTRITIVAS]
Na prática:
DELETE FROM aluno WHERE id > 10
O comando acima irá excluir todos os registros cujo id seja maior que 10. É possível 
fazer várias combinações de resultados e de operadores lógicos ou matemáticos para atin-
gir o objetivo desejado. É preciso ter cuidado com este comando para não deletar mais 
informações do que se deseja. 
2.2. Recursos
A administração de um Banco de Dados não consiste apenas em criar tabelas, mas 
também em prover recursos de otimização e facilitação da gerência do conteúdo. É bas-
tante comum que desenvolvedores de software deixem a encargo do banco de dados o 
processamento de operações que, caso fossem executadas a nível de sistema, demanda-
riam mais tempo do que para serem executadas diretamente no Banco de Dados. Assim, 
é bastante corriqueiro o uso de recursos do próprio Banco de Dados para aliviar a carga de 
trabalho dos softwares, repassando-a para o banco.
Como contrapartida, alguns recursos que veremos neste tópico são bastante úteis para 
dinamizar e dar certo grau de autonomia a um banco de dados. Estes recursos desempenham 
um papel fundamental na execução de tarefas que poderiam ser executadas manualmente.
2.2.1. Stored Procedures
Os Stored Procedures, ou, Procedimentos Armazenados, permitem que o Admi-
nistrador de Banco de Dados aloque recursos dentro do Banco de dados que serão con-
sumidos por aplicações desenvolvidas e manipuladas por usuários. O que torna esses 
procedimentos tão peculiares e práticos é a possibilidade de aceitarem sintaxes de progra-
mação (condicionais, laços de repetição, criação de variáveis, etc) em seu escopo. Assim, 
temos um código SQL com sintaxe de programação embutida. Vejamos como seria a sin-
taxe básica de um Procedure:
CREATE PROCEDURE nomeDoProc(parâmetros se for o caso tipoDeDados)
Administração de Banco de Dados62
Perceba que para criarmos um Procedure recorremos a um comando DDL: create. 
Isso será comum durante o desenvolvimento e administração de um banco de dados. 
Haverá uma mesclagem de conceitos diversos em vários momentos.
Vamos incrementar um pouco o Procedure, de forma que fique mais simples 
compreendê-lo:
CREATE PROCEDURE aumenta(maisQuanto DOUBLE, idVeiculo INT)
UPDATE veiculos SET preco = preco + maisQuanto
WHERE id = idVeiculo
No exemplo acima foi criado um procedimento simples nomeado “aumenta”, que reali-
zará a seguinte tarefa quando for invocado: receberá dois parâmetros (o primeiro com casas 
decimais e o segundo, um número inteiro); atualizará a tabela veículos, apontando no campo 
“preco” o valor atual do veículo, acrescido do valor que foi recebido como parâmetro. Esta 
atualização será realizada apenas no veículo cujo id também foi passado por parâmetro.
É normal que num primeiro momento o contexto pareça complexo por mesclar ele-
mentos de programação à SQL, que geralmente é composta apenas de linhas estrutura-
das, mas com um pouco de prática o conceito será memorizado facilmente.
Para invocar este procedimento criado, basta utilizar o comando CALL, fazendo a 
passagem dos parâmetros necessários. No exemplo abaixo o comando aumentará em 
10,00 o valor do veículo id seja 18: 
CALL AUMENTA(10.00, 18);
Os procedures aceitam blocos de comando que servem para criar pacotes de execução:
1 DELIMITER ++
2 CREATE PROCEDURE aumenta(mais DOUBLE, id INT)
3 BEGIN
4 UPDATE veiculos SET preco = preco + mais
5 WHERE id = id; 
6 END ++
7 DELIMITER ;
63Administração de Banco de Dados
Nos blocos de comando geralmente temos trechos de SQL completos com comandos 
específicos (linha 4 e 5, no caso). Como sabemos, ao final de um comando SQL é necessá-
rio inserir o ponto e vírgula caso existam novos comandos após ele. Porém, como o bloco 
está inserido dentro de um trecho que também finaliza com ponto e vírgula, o compila-
dor do Banco de Dados poderia não compreender qual bloco estaria sendo fechado e isso 
poderia causar falhas de execução.
Para sanar este problema recomendamos modificar o DELIMITADOR de bloco. Na 
linha 1 modificamos o delimitador para dois sinais de mais juntos. O delimitador fica a cri-
tério do administrador de banco de dados. Pode ser qualquer caractere, exceto o próprio 
ponto e vírgula.
O bloco de execução é escrito entre o elemento BEGIN e END. Ao final da execução, 
modificamos novamente o delimitador para ponto e vírgula (linha 7).
A declaração de variáveis dentro de um procedure deve ser feita no início do código, 
digitando o comando DECLARE e apontando os nomes das variáveis e seus respectivos tipos:
DECLARE
NOME VARCHAR(255);
IDADE INT(3);
Essas variáveis podem ser invocadas dentro dos blocos (BEGIN/END).
Procedimentos armazenados são pré-compilados, ou seja, eles ficam armazenados 
no Banco de Dados prontos para serem invocados por algum software, trigger ou direta-
mente através de uma chamada. Esta pré-compilação torna a execução do procedimento 
mais ágil que as funções, embora em sistemas pequenos e execuções simples este ganho 
de desempenho não seja visivelmente notado.
Os procedimentos também têm como item opcional valores de entrada e saída. As 
funções não têm tal recurso, ficando limitadas à recepção de parâmetros. De maneira 
similar, os procedimentos podem retornar algum valor após a execução. Este conceito de 
retorno de valor às vezes é um tanto complexo de compreender, mas basta analisar o caso 
da seguinte perspectiva: se o procedimento armazenado está no Banco de Dados pronto 
para executar alguma ação, é cabível que, após tal execução, o procedimento apresente o 
resultado obtido, seja um cálculo, uma edição, uma inserção, uma exclusão. 
Porém, os procedures não têm este retorno como regra; eles podem apenas executar 
a ação e não dar retorno algum nem ao usuário nem ao próprio banco de Dados. Caso haja 
a necessidade de se obter um retorno, talvez o uso de uma função seja o mais adequado.
Administração de Banco de Dados64
Um detalhe interessante é que Stored Procedures podem armazenar funções em seu 
escopo, enquanto as funções não podem armazenar procedimentos em suas estruturas.
Este recurso pode ser útil quando a execução sequencial de várias funções forem 
requeridas. Para atender a esta necessidade bastaria incluir todas as funções em apenas 
um procedimento armazenado e executá-lo.
Como contrapartida, os procedimentos armazenados não podem ser invocados a 
partir de SELECTS, enquanto as funções podem. Isso vale tanto para funções agregadas 
quanto para funções desenvolvidas pelo administrador do Banco de dados.
Uma característica peculiar das funções é a possibilidade que elas têm de serem utili-
zadas dentro de cláusulas WHERE/HAVING, que são cláusulas restritivas do SQL.
Pausa para refletir 
Compreender a importância dos procedimentos armazenados é fundamental para um admi-
nistrador de banco de dados. Será que você conseguiria desenvolver um procedimentoque 
seja capaz de verificar se o valor recebido por um parâmetro INTEIRO é par ou ímpar e, de 
acordo com o resultado, exibir uma mensagem na tela?
2.2.2. Functions
As funções têm o mesmo conceito que os Procedures, porém, após a execução, as fun-
ções têm como obrigatoriedade retornar algum valor, além de ser mandatório apontarem o 
tipo de dado que será retornado. A sintaxe de ambos os recursos também é bastante similar:
DELIMITER $$
CREATE FUNCTION mult(a INT, b INT)
 RETURNS int
 RETURN a * b $$
DELIMITER ;
A função acima, chamada mult recebe dois parâmetros (A e B, do tipo inteiro) e 
retorna o resultado da multiplicação entre A e B. Observe que o asterisco tem a função de 
multiplicador e não de tudo ou todos, trata-se de um dos casos de exceção, que foi citado 
anteriormente.
65Administração de Banco de Dados
Para invocar a função basta recorrer ao comando SELECT, adicionando o nome da 
função e informando os parâmetros que são esperados:
SELECT mult(10,20) AS ‘RESULTADO DA MULTIPLICAÇÃO’
O nome das funções fica a critério do administrador de banco de dados desde que na 
nomenclatura sejam respeitados os princípios dos nomes de variáveis.
2.2.3. Triggers
Os TRIGGERS (gatilhos) são eventos que são disparados automaticamente mediante 
determinadas ações DML. É importante frisar que o disparo de triggers ocorre apenas com 
DML, e não com DDL ou outras linguagens pertencente ao SQL.
A estrutura de um trigger é a seguinte:
CREATE TRIGGER NOME_TRIGGER QUANDO AÇÃO
ON NOMETABELA
FOR EACH ROW -- informo que a cada linha, execute as operações abaixo
AÇÕES A SEREM FEITAS
QUANDO: Antes ou depois da ação ser executada (BEFORE / AFTER)
AÇÃO: Insert, Delete, Update
Na prática:
1 CREATE TRIGGER fazBackup BEFORE DELETE
2 ON ALUNO
3 FOR EACH ROW
4 INSERT INTO backup(id, nome, matricula, email)
5 VALUES (OLD.id, OLD.nome, OLD.matricula, OLD.email)
Portanto temos a seguinte estrutura> 
• linha 1: o Trigger acima será disparado ANTES (BEFORE) de ocorrer um comando 
DELETE na tabela ALUNO (linha 2);
Administração de Banco de Dados66
• linha 3: para cada linha deletada o trigger vai inserir em uma outra tabela chamada 
backup, nos campos id, nome, matricula, email (linha 4), os valores atuais que 
serão apagados (linha 5);
• veja que na linha 5, antes do nome dos campos, existe a palavra OLD. Isso significa 
que estamos resgatando o valor antigo. A palavra NEW também pode ser utilizada 
em triggers, mas apenas em caso de INSERT e UPDATE. Já o OLD pode ser utili-
zado apenas com DELETE e UPDATE.
Os triggers tem usos diversos. Geralmente são utilizados para fazer verificações 
antes de confirmar uma inserção ou ainda fazer um backup, como foi o caso do exemplo 
acima. Existe ainda a possibilidade de unir triggers com procedures ou funções e realizar 
operações mais complexas de administração de um banco de dados.
Proposta de Atividade
Reforce seu aprendizado com o exercício sugerido a seguir. A atividade não é avaliativa, 
mas é uma boa oportunidade para testar seus conhecimentos e fixar o conteúdo estudado no capítulo.
Agora é a hora de recapitular tudo o que você aprendeu neste capítulo! Desenvolva um 
banco de dados para gerenciar e armazenar os dados de hóspedes de um hotel. Este banco 
contará com 3 (três) tabelas:
• Hospede (id, nome, email, cpf);
• Quartos (id, andar, camas, valor);
• Alimentacao (id, tipo, valor).
O campo tipo será utilizado para referenciar qual o tipo da alimentação: Café da manhã, 
almoço, Janta.
Após criar o Banco de Dados criado, preencha algumas informações em todas as tabelas uti-
lizando os comandos DML específicos. Em seguida, crie uma trigger que a cada atualiza-
ção salve numa outra tabela do banco (que você também deverá criar) um backup dos dados 
anteriores.
Crie também um procedure ou função que acrescente uma taxa de 10% de serviço de quarto 
ao valor a ser cobrado pela hospedagem diária.
67Administração de Banco de Dados
Recapitulando
Vimos neste capítulo que com comandos DDL (Data Definition Language) é possí-
vel trabalhar elementos estruturais de um Banco de Dados. Já comandos DML (Data Mani-
pulation Language) atuam diretamente sobre os registros salvos. Atrelados aos comandos 
DML, temos as cláusulas de restrição, que limitam os registros que serão afetados por uma 
edição, exclusão ou aqueles que serão exibidos numa consulta.
Como recursos adicionais, temos os Triggers, responsáveis por disparar ações 
mediante a inclusão, exclusão ou atualização de registros. Temos também os procedures 
que, similares às funções, armazenam recursos que são executados diretamente no banco 
de dados, podendo ser consumidos de forma externa. As funções têm como característica 
a obrigatoriedade de retornar um valor enquanto este recurso é opcional nos procedures.
Um administrador de Banco de Dados precisa, assim como outros profissionais de TI, 
especificamente na área de Programação, compreender que o conteúdo aprendido pode e 
deve sempre ser aprimorado.
Na proposta citada no início deste capítulo, propusemos que você tentasse imaginar 
uma estrutura de Banco de Dados para um hipermercado. Esta estrutura deveria ser capaz de 
armazenar o cadastro de fornecedores, funcionários, clientes, produtos e frota de veículos.
Com base no que vimos até então, vamos abstrair do mundo real as tabelas que estão 
envolvidas nesta estrutura. Lembre-se que esta extração deve ser feita pensando sempre 
no conjunto de tabelas, pois isso nos fornecerá possíveis relações existentes (o tema rela-
cionamento de tabelas será abordado em outros capítulos).
Saiba que a estrutura proposta não é mandatória, ou seja, pode ser adaptada de 
acordo com cada necessidade. Considere-a apenas como uma base. Desta maneira, os 
campos a serem inseridos nessa tabela também são mutáveis. Direcione seu foco, neste 
primeiro momento, apenas à formação do conceito sobre a estrutura e leia a formação 
abaixo como exemplos daquilo que poderia ser desenvolvido.
TABELAS:
• Fornecedores.
• Funcionários.
• Clientes.
• Produtos.
• Veículos.
Administração de Banco de Dados68
 TRIGGERS
• trigger de Backup em todas as tabelas, para armazenar os valores em caso de alte-
ração ou exclusão de dados;
• trigger em todas as tabelas para registrar os usuários que fizeram a exclusão de
algum dado, dentre outros.
FUNÇÕES / PROCEDURES
• funções que pudessem manipular o valor de um produto, calculando automatica-
mente o valor do imposto a ser impresso na nota fiscal do cliente;
• funções que poderiam verificar a quantidade de veículos disponíveis para entrega
no momento e habilitariam ou não a venda de um determinado produto;
• funções que, mediante o cadastro de um novo funcionário, disparariam mensa-
gens internas a todos os departamentos, como meio de informar a todos os seto-
res sobre um novo membro da equipe, entre outros recursos.
Salientamos que esta base acima é apenas uma proposta de estrutura fictícia. Outros 
recursos poderiam ser adicionados, enquanto alguns poderiam ser suprimidos. O ideal, 
antes de iniciar qualquer projeto de Banco de Dados, é elaborar a estrutura que o projeto 
terá para então partir para os critérios de modelagem e desenvolvimento do banco por 
meio das linhas de comando.