9 Banco de Dados Completo

FUNDAMENTOS
COMPUTACIONAIS
Ramiro Córdova Júnior

Banco de dados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
Conceituar banco de dados.

Identificar os tipos de banco de dados.
Classificar os tipos de linguagens de bancos de dados.
Introdução
Atualmente, os sistemas de informação são desenvolvidos juntamente
com uma base de dados. Essa base é responsável por gerenciar a manipu-
lação dos dados utilizados. Por isso, é fundamental que os profissionais da
área de desenvolvimento de sistemas tenham o conhecimento adequado
sobre os bancos de dados. Assim, esses profissionais podem integrar
sistemas e bancos de dados de maneira conveniente.
Neste capítulo, você vai conhecer a definição de banco de dados,
associando-a a exemplos. Além disso, vai ver os diferentes tipos de banco
de dados e a linguagem utilizada neles.
Conceito de banco de dados

Um banco de dados é uma coleção de informações organizadas para que
possam ser facilmente acessadas, gerenciadas e atualizadas. Os dados são
organizados em linhas, colunas e tabelas e são indexados para facilitar a
localização de informações relevantes. Os dados são atualizados e excluídos
à medida que novas informações são adicionadas. Os bancos de dados pro-
cessam informações e permitem a consulta dos dados armazenados. Além
disso, permitem a execução de aplicações na base de dados.
Os bancos de dados computacionais geralmente contêm registros agrega-
dos ou arquivos de dados, que representam transações de vendas, catálogos
de produtos, inventários, perfis de clientes, etc. Normalmente, um sistema
gerenciador de banco de dados (SGBD) fornece aos usuários a capacidade
174 Banco de dados
de controlar o acesso de leitura/gravação, definir a geração de relatórios e

realizar procedimentos de análise dos dados. Bancos de dados são predomi-
nantes em grandes sistemas de mainframe, mas também estão presentes em
estações de trabalho distribuídas menores e sistemas de médio porte, como
em computadores pessoais.
Um banco de dados pode ser considerado um software estruturado para
coletar e armazenar informações que possam ser recuperadas, adicionadas,
atualizadas ou removidas de maneira automática. Os programas de banco de
dados são aplicativos projetados para que os usuários criem bancos de dados
e toda a programação necessária para preenchê-los ou excluí-los, conforme
necessário. A estrutura de um banco de dados (Figura 1) é baseada em tabelas,
que consistem em linhas e colunas de informações. As colunas identificam
os dados (atributos) na tabela e as linhas são os registros de informações. As
tabelas se parecem com uma planilha, mas podem ser manipuladas e atuali-
zadas de uma forma que as planilhas não podem. Como você pode imaginar,
isso torna um banco de dados uma ferramenta muito valiosa.
Colunas
NumEmp NomeEmp Salário Dept

032 J Silva 380 21
074 M Reis 400 25
089 C Melo 520 28
Linhas
092 R Silva 480 25
112 R Pinto 390 21
121 V Simão 905 28
130 J Neves 640 28
Figura 1. Estrutura do banco de dados.
Uma estrutura de banco de dados é definida pelo modelo de banco de dados.

O modelo mais usado é o modelo de banco de dados relacional. Nesse modelo, as
tabelas devem relacionar-se ou vincular-se umas às outras. Cada tabela contém
informações específicas ou atributos (colunas) para cada registro (linha). Por
exemplo, um banco de dados de uma clínica veterinária pode ter uma tabela
Pacientes — com colunas intituladas Nome do paciente, Tipo de paciente e
Banco de dados 175
Número de ID — e uma segunda tabela chamada Proprietário do paciente —

com as colunas intituladas Número de identificação, Nome do proprietário,
Endereço do proprietário e Número de telefone do proprietário. A primeira
tabela é vinculada à segunda tabela pelo número de ID. O relacionamento do
número de ID permite a localização de registros dos pacientes vinculando
com seus proprietários, retornando uma resposta precisa na realização de
consultas no banco de dados.
O projeto de um banco de dados deve ser baseado nos requisitos de negócio.
Os requisitos de negócio, por sua vez, devem ser perfeitamente compreendidos
antes que um banco de dados seja projetado. Os requisitos de negócio também
podem ser chamados de regras de negócios. As tabelas devem conter no
máximo um conjunto de informações. No caso do exemplo anterior, a tabela
Paciente não deve conter informações sobre as visitas dos pacientes. Em vez
disso, uma tabela separada manteria um número de ID de visita e a data e a
hora da visita, juntamente com o número de ID do paciente, para vincular os
dois. Uma quarta tabela, intitulada Faturamento, seria criada para identificar
o valor do pagamento, o tipo de pagamento e o ID da visita, que está sendo
pago juntamente com o ID do paciente. As tabelas Faturamento e Visitas
fazem parte da regra de negócio.
A inserção de registros preenche um banco de dados com dados. Depois
que o banco de dados é estruturado corretamente, uma interface é construída.
Essa interface é colocada entre as tabelas e o usuário. A interface dá ao
usuário uma visão diferente do banco de dados. Usando o exemplo da clínica
veterinária, uma interface pode fornecer ao usuário uma página de entrada
chamada Novo usuário. Nessa página, o usuário pode inserir o nome e o
tipo do animal de estimação, as informações do proprietário e a data e o tipo
da primeira visita. Todas essas informações estão contidas em três tabelas
diferentes localizadas atrás da interface, mas o usuário só precisa interagir
com a página de entrada (um único formulário), enquanto os dados são
armazenados nas tabelas corretas. Isso é conseguido conectando as tabelas
por meio de recursos de programação.
Acesse o link a seguir e leia mais sobre conceitos de banco de dados.
https://goo.gl/faJXMp
176 Banco de dados
Tipos de banco de dados

Segundo Geremia (2010), são quatro os tipos de banco de dados existentes: (1)
banco de dados relacional; (2) banco de dados hierárquico; (3) banco de dados
em rede; e (4) banco de dados objeto-relacional. A seguir, você vai conhecer
melhor cada um deles.
Banco de dados relacional

O banco de dados do tipo relacional funciona como uma coleção de relações,
em que cada linha representa um conjunto de dados relacionados entre si.
Os dados contidos em uma linha do banco de dados representam fatos do
mundo real. Um banco de dados relacional é uma coleção de itens de dados
organizados como um conjunto de tabelas formalmente descritas. A partir
desse conjunto, os dados podem ser acessados ou remontados de muitas
maneiras diferentes sem a necessidade de se reorganizarem as tabelas do
banco de dados. Além de ser relativamente fácil de se criar e acessar, um
banco de dados relacional tem a importante vantagem de ser fácil de estender.
Após a criação do banco de dados original, uma nova categoria de dados
pode ser adicionada sem a exigência de que todos os aplicativos existentes
sejam modificados.
Um banco de dados relacional é um conjunto de tabelas contendo dados
ajustados em categorias predefinidas. Cada tabela contém uma ou mais ca-
tegorias de dados nas colunas. Cada linha contém uma instância única de
dados para as categorias definidas pelas colunas. Por exemplo, um banco
de dados de entrada de pedidos comerciais típico incluiria uma tabela que
descreve um cliente com colunas para nome, endereço, número de telefone e
assim por diante. Outra tabela descreveria um pedido: produto, cliente, data,
preço de venda e assim por diante. Um usuário do banco de dados poderia
obter uma visão do banco de dados que atendesse às suas necessidades. Por
exemplo, um gerente da filial poderia gostar de visualizar ou relatar todos os
clientes que compraram produtos após determinada data. Já um gerente de
serviços financeiros da mesma empresa poderia, nas mesmas tabelas, obter
um relatório sobre as contas que precisam ser pagas.
Banco de dados hierárquico

Um banco de dados hierárquico usa diferentes níveis de dados que seguem
um padrão semelhante a uma hierarquia. Em outras palavras, você começa
Banco de dados 177
em uma tabela e, dependendo do registro consultado, obtém acesso a outras

tabelas de informações. No entanto, essas tabelas são vinculadas apenas à
tabela acima ou à tabela abaixo. Isso as torna incrivelmente úteis para coletar
informações que seguem uma ordem específica.
Bancos de dados hierárquicos são úteis quando duas condições são aten-
didas. Em primeiro lugar, os dados devem seguir um padrão hierárquico
(Figura 2). Isso significa que deve haver relacionamentos entre os dados que
poderiam estar “empilhados”, como em uma árvore genealógica. Em segundo
lugar, os dados que estão sendo empilhados devem estar acessíveis apenas
por meio de um único caminho.
Fábrica Financeiro Comercial
Injeção Extrusão Pagar Receber Contábil Vendas Marketing
Paulo Vinícius Vilma Sílvia João Pedro Carlos
Figura 2. Hierarquia em bancos de dados.
Banco de dados em rede

O banco de dados em rede (Figura 3) é um modelo de banco de dados
que permite que vários registros sejam vinculados ao mesmo arquivo de
proprietário. O modelo pode ser visto como uma árvore invertida, onde os
ramos são as informações do membro ligadas ao proprietário, que é a parte
inferior da árvore. As múltiplas conexões permitem que o banco de dados
de rede seja muito flexível. Além disso, a relação que a informação tem
com o banco de dados de rede é definida como relação muitos para muitos,
porque um arquivo proprietário pode ser vinculado a vários arquivos de
membros e vice-versa.
178 Banco de dados
Departamento Empregado
032 J Silva 380
074 M Reis 400

21 Pessoal 142
089 C Melo 520
25 Financeiro 143 092 R Silva 480
112 R Pinto 390

28 Técnico 144
121 V Simão 905
130 J Neves 640
Figura 3. Rede de banco de dados.
Banco de dados objeto-relacional

O modelo relacional de objeto é projetado para fornecer um gerenciamento de
banco de dados relacional que permite aos desenvolvedores integrar bancos
de dados com seus tipos e métodos de dados. É essencialmente um modelo
relacional que permite aos usuários integrarem nele recursos de programação
orientada a objetos. A principal função desse tipo de banco de dados é dar
maior flexibilidade, melhor desempenho e maior integridade de dados que os
demais tipos de banco de dados. A seguir, você pode ver alguns dos benefícios
proporcionados pelo banco de dados objeto-relacional.
Expansibilidade: é possível ampliar a capacidade do servidor de banco

de dados. Isso pode ser feito definindo novos tipos de dados, bem como
por meio de padrões definidos pelo usuário. Esse recurso permite que
o usuário armazene e gerencie dados.
Tipos de dados complexos: os usuários podem definir novos tipos de
dados que combinam um ou mais tipos de dados existentes no momento.
Os tipos complexos garantem melhor flexibilidade na organização dos
dados em uma estrutura composta de colunas e tabelas.
Herança: os usuários podem definir objetos ou tipos e tabelas que
adquirem as propriedades de outros objetos, além de adicionar novas
propriedades específicas ao objeto que foi definido.
Banco de dados 179
Leia mais sobre sistemas de banco de dados na obra “Sistemas de banco de dados”
(ELMASRI, R.; NAVATHE, S. B., 2005).
Linguagens de banco de dados

Um sistema gerenciador de banco de dados deve prover linguagens e inter-
faces apropriadas para que cada categoria de usuários realize consultas e
atualizações no banco de dados. As linguagens de banco de dados são usadas
para a criação e a manutenção do banco de dados. Há um grande número de
linguagens de banco de dados, como Oracle, MySQL, MS Access, dBase,
FoxPro, etc. As instruções SQL usadas em um banco de dados podem ser
categorizadas como linguagem de definição de dados (DDL), linguagem de
controle de dados (DCL) e linguagem de manipulação de dados (DML). Você
vai conhecer melhor cada uma delas a seguir.
Linguagem de definição de dados (DDL)

É uma linguagem que permite aos usuários definir dados e sua relação com outros
tipos de dados. É usada principalmente para criar arquivos, bancos de dados, dicio-
nário de dados e tabelas dentro de bancos de dados. Também serve para especificar
a estrutura de cada tabela, o conjunto de valores associados a cada atributo, as
restrições de integridade, as informações de segurança e autorização para cada
tabela e o armazenamento físico da estrutura de cada tabela no disco. A seguir,
você pode ver uma lista de instruções SQL que são categorizadas como DDL.
Para criar a instância do banco de dados — CREATE

Para alterar a estrutura do banco de dados — ALTER
Para descartar instâncias do banco de dados — DROP
Para excluir tabelas em uma instância de banco de dados — TRUNCATE
Para renomear instâncias do banco de dados — RENAME
Linguagem de manipulação de dados (DML)

É uma linguagem que fornece um conjunto de operações para suportar as
operações básicas de manipulação nos dados mantidos nos bancos de dados.
180 Banco de dados
As instruções DML permitem que os usuários insiram, atualizem, excluam

e recuperem dados do banco de dados. A parte do DML que envolve a recu-
peração de dados é chamada de linguagem de consulta. A seguir, você pode
ver algumas instruções SQL que são do tipo DML.
Para buscar registros da(s) tabela(s) — SELECT

Para inserir registros na(s) tabela(s) — INSERT
Para atualizar os dados na(s) tabela(s) — UPDATE
Para excluir os registros da tabela — DELETE
Linguagem de controle de dados (DCL)

As instruções do tipo DCL controlam o acesso aos dados e ao banco de dados
usando instruções SQL como GRANT e REVOKE. Um privilégio pode ser
concedido a um usuário com a ajuda da instrução GRANT. Os privilégios
atribuídos podem ser instruções do tipo SELECT, ALTER, DELETE, EXE-
CUTE, INSERT, INDEX, etc. Além da concessão de privilégios, também é
possível revogar usando o comando REVOKE.
Na prática, as linguagens de definição de dados e de manipulação de
dados não são separadas. Em vez disso, elas formam partes de uma única
linguagem de banco de dados, como SQL (Structured Query Language). O
SQL representa uma combinação de DDL e DML, além de instruções para
especificação de restrições e avaliação de esquemas.
Referência
GEREMIA, J. Tutorial de introdução a banco de dados. 2010. Disponível em: <http://

www.telecom.uff.br/pet/petws/downloads/tutoriais/db/Tut_DB.pdf>. Acesso em;
22 abr. 2018.
Leituras recomendadas
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. São Paulo: Pearson, 2005.
REZENDE, R. Conceitos fundamentais de banco de dados. [201-?]. Disponível em: <ht-
tps://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>.
Acesso em; 22 abr. 2018.
SANTANCHÈ, A.; CAVOTO, P. Banco de dados. Campinas: [S.n.], (2013).
Sistemas de Gerenciamento
de Banco de Dados
Tradução da
Terceira Edição
Ramakrishnan • Gehrke
SISTEMAS DE GERENCIAMENTO
DE BANCO DE DADOS
Tradução da Terceira Edição
Raghu Ramakrishnan
University of Wisconsin
Madison, Wisconsin, USA
Johannes Gehrke
Cornell University
Ithaca, New York, USA
Tradução
Célia Taniwake
João Eduardo Nóbrega Tortello
Revisão Técnica
Elaine Parros Machado de Sousa
Professora Doutora do Departamento de Ciências de Computação —
Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo
Versão impressa
desta obra: 2008
2011
1
VISÃO GERAL SOBRE
SISTEMAS DE BANCO DE DADOS
☛ O que é um SGBD, em particular, um SGBD relacional?

☛ Por que devemos utilizar um SGBD para gerenciar dados?
☛ Como os dados da aplicação são representados em um SGBD?
☛ Como os dados em um SGBD são recuperados e manipulados?
☛ Como um SGBD suporta o acesso concorrente e protege os dados na ocorrência
de falhas no sistema?
☛ Quais são os principais componentes de um SGBD?
☛ Quem está envolvido com bancos de dados na vida real?
➽ Conceitos-chave: gerenciamento de banco de dados, independência de dados, pro-
jeto de banco de dados, modelo de dados; bancos de dados e consultas relacionais;
esquemas, níveis de abstração; transações, concorrência e bloqueio, recuperação e
registro em log; arquitetura de um SGBD; administrador de um banco de dados,
programador do aplicativo, usuário final.
Reparou que todas as letras da palavra database (banco de dados, em inglês) são
digitadas com a mão esquerda? Sabemos que a disposição do teclado da máquina de
escrever (QWERTY) foi projetada, entre outras coisas, para facilitar o uso uniforme
de ambas as mãos. Conclui-se, então, que escrever sobre bancos de dados, além de ser
algo não natural, é bem mais difícil do que parece.
— Anônimo
A quantidade de informações que nos são disponíveis está literalmente explodindo, e o

valor dos dados como um ativo organizacional é amplamente reconhecido. Para obter
a maior parte de seus grandes e complexos conjuntos de dados, os usuários necessitam
de ferramentas que simplifiquem as tarefas de gerenciamento dos dados e a extração
de informações úteis de forma oportuna. Caso contrário, os dados podem se tornar
2
Visão Geral sobre Sistemas de Banco de Dados 3
A área de sistemas de gerenciamento de dados é um microcosmo da Ciên-

cia da Computação em geral. Os aspectos tratados e as técnicas utilizadas
abrangem um amplo espectro, incluindo linguagens, orientação a objeto e ou-
tros paradigmas de programação, compilação, sistemas operacionais, progra-
mação concorrente, estruturas de dados, algoritmos, teoria, sistemas distri-
buídos e paralelos, interfaces do usuário, sistemas especialistas e inteligência
artificial, técnicas estatísticas e programação dinâmica. Não podemos tratar
todos esses aspectos de gerenciamento de banco de dados em um livro, mas
esperamos prover ao leitor um sentido de investigação nesta disciplina rica
e vibrante.
um passivo, cujo custo de aquisição e gerenciamento excede em muito o valor por ele
produzido.
Um banco de dados é uma coleção de dados que, tipicamente, descreve as ativida-
des de uma ou mais organizações relacionadas. Por exemplo, um banco de dados de
uma universidade poderia conter informações sobre:
■ Entidades como alunos, professores, cursos e turmas.

■ Relacionamentos entre as entidades, como a matrícula dos alunos nos cursos, cur-
sos ministrados pelos professores, e o uso de salas por cursos.
Um sistema de gerenciamento de banco de dados, ou SGBD, é um software proje-

tado para auxiliar a manutenção e utilização de vastos conjuntos de dados. A neces-
sidade de tais sistemas, assim como seu uso, tem crescido rapidamente. A alternativa
para não se usar um SGBD é armazenar os dados em arquivos e escrever código es-
pecífico do aplicativo para gerenciá-los. O uso de um SGBD tem diversas vantagens
importantes, como veremos na Seção 1.4.
1.1 GERENCIANDO DADOS

O objetivo deste livro é apresentar uma introdução detalhada dos sistemas de geren-
ciamento de banco de dados, com ênfase em como projetar um banco de dados e como
usar efetivamente um SGBD. Naturalmente, várias decisões sobre como utilizar um
SGBD para um determinado aplicativo dependem de quais recursos o SGBD suporta
de forma eficiente. Assim, para aproveitar bem um SGBD, é necessário compreender
também como ele funciona.
Diversos tipos de sistemas de gerenciamento de banco de dados estão em uso, mas
este livro concentra-se nos sistemas de banco de dados relacionais (SGBDRs), que com
certeza constituem o tipo dominante de SGBD nos dias atuais. As seguintes questões
são tratadas nos capítulos principais deste livro:
1. Projeto de Banco de Dados e Desenvolvimento de Aplicativo: Como um usuário

pode descrever uma empresa do mundo real (por exemplo, uma universidade)
em termos dos dados armazenados em um SGBD? Que fatores devem ser con-
siderados ao decidir sobre a forma de organização dos dados armazenados?
Como podemos desenvolver aplicativos que dependem de um SGBD? (Capítulos
2, 3, 6, 7, 19, 20 e 21.)
4 CAPÍTULO 1
2. Análise dos Dados: Como um usuário pode responder a dúvidas sobre a empresa
formulando consultas sobre os dados do SGBD? (Capítulos 4 e 5.)1
3. Concorrência e Robustez: Como um SGBD permite que vários usuários acessem os
dados de forma concorrente, e como ele protege os dados na ocorrência de falhas do
sistema? (Capítulos 16, 17 e 18.)
4. Eficiência e Escalabilidade: Como um SGBD armazena grandes conjuntos de dados
e responde a questões sobre esses dados de forma eficiente? (Capítulos 8, 9, 10, 11,
12, 13, 14 e 15.)
Os capítulos posteriores abrangem tópicos importantes que estão evoluindo rapida-

mente, como o gerenciamento de banco de dados distribuído e paralelo, armazenagem
de dados e consultas complexas para apoio à decisão, mineração de dados, recuperação
de banco de dados e informações, repositórios XML, banco de dados orientado a obje-
tos, gerenciamento de dados espaciais, e extensões de SGBD orientado a regras.
No restante deste capítulo, introduziremos estes tópicos. Na Seção 1.2, começamos
com uma breve história da área e uma discussão do papel do gerenciamento de banco
de dados nos sistemas de informações modernos. Identificaremos, então, os benefícios
de armazenar os dados em um SGBD em vez de em um sistema de arquivos, na Se-
ção 1.3, e, na Seção 1.4, discutiremos as vantagens de usar um SGBD para gerenciar
dados. Na Seção 1.5, apresentaremos como as informações sobre uma empresa devem
ser organizadas e armazenadas em um SGBD. Um usuário provavelmente pensa sobre
as informações num alto nível, que corresponde às entidades da organização e seus rela-
cionamentos, enquanto o SGBD basicamente armazena os dados na forma de (vários e
vários) bits. A lacuna existente entre como os usuários pensam sobre seus dados e como
os dados são definitivamente armazenados é preenchida através de diversos níveis de
abstração suportados pelo SGBD. Intuitivamente, um usuário pode começar descreven-
do os dados em termos totalmente de alto nível, e depois melhorar a descrição conside-
rando o armazenamento adicional e detalhes de representação conforme necessário.
Na Seção 1.6, consideraremos como os usuários podem recuperar os dados armaze-
nados em um SGBD e a necessidade de técnicas para processar eficientemente respos-
tas às consultas envolvendo tais dados. Na Seção 1.7, forneceremos uma visão geral
sobre como um SGBD suporta o acesso concorrente aos dados por diversos usuários e
como ele protege os dados na ocorrência de falhas do sistema.
Descreveremos, então, brevemente, a estrutura interna de um SGBD na Seção 1.8,
e, na Seção 1.9, mencionaremos vários grupos de pessoas associadas com o desenvolvi-
mento e uso de um SGBD.
1.2 UMA PERSPECTIVA HISTÓRICA

Desde os primeiros computadores, armazenar e manipular dados têm sido o principal
foco dos aplicativos. O primeiro SGBD de propósito geral, projetado por Charles Ba-
chman, na General Electric, no início da década de 1960, foi chamado Depósito de Da-
dos Integrados (Integrated Data Store). Ele constituiu a base do modelo de dados de
rede, que foi padronizado pela Conference on Data Systems Languages (CODASYL)
e influenciou bastante os sistemas de banco de dados na década de 1960. Bachman foi
o primeiro a ser contemplado pelo Prêmio Turing da ACM (o equivalente ao Prêmio
Nobel na Ciência da Computação) pelo trabalho na área de banco de dados; ele rece-
beu o prêmio em 1973.
1Um capítulo on-line sobre Consulta por Exemplo (QBE — Query-by-Example) também está disponível.
Veja mais informações no Prefácio.
No final da década de 1960, a IBM desenvolveu o SGBD Sistema de Gerenciamento

de Informação (IMS — Information Management System), ainda usado atualmente
em diversas instalações. O IMS constituiu a base da estrutura de representação al-
ternativa de dados, chamada modelo de dados hierárquico. O sistema SABRE para
reservas de passagens aéreas foi desenvolvido em conjunto pela American Airlines e
pela IBM nessa mesma época, e permitiu que diversas pessoas acessassem os mesmos
dados através de uma rede de computadores. Interessante observar que, atualmente, o
mesmo sistema SABRE é utilizado para fornecer serviços populares de viagens basea-
dos na Web, tais como o Travelocity.
Em 1970, Edgar Codd, do Laboratório de Pesquisa de San Jose, da IBM, propôs
uma nova estrutura de representação de dados chamada modelo de dados relacional,
que veio a ser um marco histórico no desenvolvimento de sistemas de banco de da-
dos. Ele impulsionou o rápido desenvolvimento de vários SGBDs baseados no modelo
relacional, juntamente com um rico conjunto de resultados teóricos que consolidaram
firmemente a área. Codd ganhou o Prêmio Turing de 1981 pelo seu trabalho original.
Os sistemas de banco de dados amadureceram como uma disciplina acadêmica, e a
popularidade dos SGBDs relacionais alterou o cenário comercial. Seus benefícios fo-
ram amplamente reconhecidos, e o uso de SGBDs para gerenciar dados corporativos
tornou-se uma prática padrão.
Na década de 1980, o modelo relacional consolidou sua posição como o paradigma
dominante de SGBD, e o uso dos sistemas de banco de dados continuou a se difundir
cada vez mais. A linguagem de consulta SQL para banco de dados relacional, desen-
volvida como parte do projeto System R, da IBM, passou a ser a linguagem de consul-
ta padrão. A SQL foi padronizada no final dos anos 80, e o padrão atual, SQL:1999 foi
adotado pelo American National Standards Institute (ANSI) e pela International Or-
ganization for Standardization (ISO). É possível argumentar que a forma mais ampla-
mente utilizada de programação concorrente é a execução concorrente de programas
de banco de dados (chamados transações). Os usuários escrevem os programas como
se eles fossem executar isoladamente, e a responsabilidade de executá-los de forma
concorrente é atribuída ao SGBD. James Gray ganhou o Prêmio Turing de 1999 pelas
suas contribuições ao gerenciamento de transações de banco de dados.
No final da década de 1980 e na década de 1990, houve avanços em diversas áreas
dos sistemas de banco de dados. Pesquisas consideráveis foram conduzidas para desen-
volver linguagens de consulta mais poderosas e modelos de dados mais ricos, com ênfa-
se no suporte à análise complexa de dados provenientes de todas as áreas da empresa.
Diversos fabricantes (como o DB2 da IBM, Oracle 8, Informix2 UDS) estenderam seus
sistemas com a capacidade de armazenar novos tipos de dados, como imagens e texto,
e a possibilidade de consultas mais complexas. Sistemas especializados têm sido desen-
volvidos por inúmeros fabricantes para criação de data warehouses, consolidando os
dados de diversos bancos de dados, com o intuito de conduzir análise especializada.
Um fenômeno interessante é a emergência de diversos pacotes de planejamento de
recurso empresarial (ERP — enterprise resource planning) e de planejamento de re-
curso de gerenciamento (MRP — management resource planning), que acrescentaram
uma camada substancial de recursos orientados a aplicativos acima de um SGBD. Os
pacotes largamente utilizados incluem sistemas da Baan, Oracle, PeopleSoft, SAP
e Siebel. Esses pacotes identificam um conjunto de tarefas comuns (por exemplo,
gerenciamento de inventário, planejamento de recursos humanos, análise financeira)
desempenhadas por um grande número de organizações e fornecem uma camada de
aplicativo genérica para realizar essas tarefas. O dado é armazenado em um SGBD
2 A Informix foi recentemente adquirida pela IBM.

6 CAPÍTULO 1
relacional, e a camada de aplicativo pode ser customizada para empresas diferentes,

diminuindo os custos totais para as organizações, comparados ao custo de criar uma
camada de aplicativo a partir do zero.
O fato histórico mais significativo, talvez, seja a entrada dos SGBDs na Era Inter-
net. Enquanto a primeira geração de web sites armazenava seus dados exclusivamente
em arquivos dos sistemas operacionais, o uso de um SGBD para armazenar dados
acessados através de um navegador Web tem se difundido cada vez mais. As consultas
são geradas através de formulários acessíveis na Web e as respostas são formatadas
usando uma linguagem de marcação como o HTML para serem facilmente exibidas em
um navegador. Todos os fabricantes de banco de dados estão acrescentando recursos
aos seus SGBDs com o objetivo de torná-los mais adequados para desenvolvimento
para Internet.
O gerenciamento de banco de dados continua a ganhar importância conforme mais
e mais dados tornam-se disponíveis on-line e ainda mais acessíveis através da rede
de computadores. Atualmente, a área está sendo impulsionada por ideais excitantes.
Entre eles temos: banco de dados multimídia, vídeo interativo, fluxos de dados, biblio-
tecas digitais, um hospedeiro de projetos científicos, como o esforço de mapeamento
do genoma humano, e o projeto de Sistema de Observação Terrestre da NASA, além
do desejo das empresas de consolidar seus processos de tomada de decisão e minerar
seus repositórios de dados por informações úteis sobre seus negócios. Comercialmente,
os sistemas de gerenciamento de banco de dados representam um dos maiores e mais
ativos segmentos de mercado. Assim, o estudo de sistemas de banco de dados pode vir
a ser ricamente gratificante e não apenas de uma maneira, mas de várias!
1.3 ARQUIVOS DE SISTEMAS VERSUS UM SGBD

Para compreendermos a necessidade de um SGBD, consideremos um cenário motiva-
dor: uma empresa tem uma grande coleção (digamos 500 GB3) de dados sobre os fun-
cionários, departamentos, produtos, vendas e assim por diante. Esse dado é acessado
concorrentemente por diversos funcionários. As consultas sobre os dados devem ser
respondidas rapidamente, as alterações realizadas nos dados pelos diferentes usuários
devem ser aplicadas consistentemente, e o acesso a determinadas partes dos dados
(por exemplo, salários) deve ser restrito.
Podemos experimentar gerenciar os dados armazenando-os em arquivos do sistema
operacional. Essa abordagem tem várias desvantagens, que incluem:
■ Provavelmente, não teremos 500 GB de memória principal para armazenar todos os

dados. Devemos, então, armazenar os dados em um dispositivo de armazenamento,
como disco ou fita, e carregar partes relevantes dos dados na memória principal
conforme necessário.
■ Mesmo que tivéssemos 500 GB de memória principal, num sistema computacional
de 32 bits de endereçamento, não podemos nos referir diretamente a mais do que
aproximadamente 4 GB de dados. Temos que programar algum método de identi-
ficação de todos os itens de dados.
■ Devemos escrever programas especiais para responder a cada pergunta que um
usuário pode desejar fazer sobre os dados. Esses programas provavelmente serão
complexos em razão do grande volume de dados a ser pesquisado.
3Um kilobyte (KB) são 1024 bytes, um megabyte (MB) são 1024 KBs, um gigabyte (GB) são 1024 MBs,
um terabyte (TB) são 1024 GBs, e um petabyte (PB) são 1024 terabytes.
■ Devemos proteger os dados de alterações inconsistentes realizadas por usuários

diferentes acessando os dados de forma concorrente. Se os aplicativos devem tratar
dos detalhes desse acesso concorrente, isto aumenta significativamente a sua com-
plexidade.
■ Devemos assegurar que os dados sejam restaurados a um estado consistente se o
sistema falhar enquanto as alterações estão sendo realizadas.
■ Os sistemas operacionais provêm apenas um mecanismo de senha para segurança.
Isso não é suficientemente flexível para reforçar as políticas de segurança nas quais
usuários diferentes têm permissão de acessar subconjuntos diferentes dos dados.
Um SGBD é um pacote de software projetado para executar mais facilmente as

tarefas mencionadas anteriormente. Armazenando-se dados em um SGBD em vez de
em uma coleção de arquivos do sistema operacional, é possível utilizar os recursos do
SGBD para gerenciar os dados de uma forma robusta e eficiente. À medida que cresce
o volume de dados e o número de usuários — centenas de gigabytes de dados e milha-
res de usuários são comuns nos bancos de dados corporativos atuais —, o suporte de
um SGBD torna-se indispensável.
1.4 VANTAGENS DE UM SGBD

Usar um SGBD para gerenciar dados tem várias vantagens:
■ Independência de Dados: Os programas aplicativos não devem, idealmente, ser

expostos aos detalhes de representação e armazenamento de dados. O SGBD provê
uma visão abstrata dos dados que oculta tais detalhes.
■ Acesso Eficiente aos Dados: Um SGBD utiliza uma variedade de técnicas sofisti-
cadas para armazenar e recuperar dados eficientemente. Este recurso é especial-
mente importante se os dados são armazenados em dispositivos de armazenamen-
to externos.
■ Integridade e Segurança dos Dados: Se os dados são sempre acessados através
do SGBD, ele pode forçar restrições de integridade. Por exemplo, antes de in-
serir informações sobre o salário de um funcionário, o SGBD pode verificar se o
orçamento do departamento não está se excedendo. Além disso, ele pode forçar
controles de acesso que governam quais dados estão visíveis a diferentes classes
de usuários.
■ Administração de Dados: Quando diversos usuários compartilham dados, cen-
tralizar a administração dos dados pode oferecer melhorias significativas. Profis-
sionais experientes que compreendem a natureza dos dados sendo gerenciados, e
como os diferentes grupos de usuários os utilizam, podem ser responsáveis por
organizar a representação dos dados para minimizar a redundância e para realizar
as sintonizações finas do armazenamento dos dados para garantir uma eficiente
recuperação.
■ Acesso Concorrente e Recuperação de Falha: Um SGBD planeja o acesso concor-
rente aos dados de maneira tal que os usuários podem achar que os dados estão
sendo acessados por apenas um único usuário de cada vez. Além disso, o SGBD
protege os usuários dos efeitos de falhas de sistema.
■ Tempo Reduzido de Desenvolvimento de Aplicativo: Obviamente, o SGBD supor-
ta funções importantes que são comuns a vários aplicativos que acessam os dados
no SGBD. Isso, em conjunto com uma interface de alto nível aos dados, facilita
o desenvolvimento rápido de aplicativos. Os aplicativos de SGBD tendem a ser
8 CAPÍTULO 1
mais robustos do que os aplicativos similares independentes porque muitas tarefas

importantes são tratadas pelo SGBD (e não precisam ser depuradas e testadas no
aplicativo).
Dadas todas essas vantagens, há alguma razão para não se utilizar um SGBD? Al-
gumas vezes, sim. Um SGBD é um software complexo, otimizado para alguns tipos de
processamento (por exemplo, responder a consultas complexas ou tratar várias requisi-
ções concorrentes), e seu desempenho pode não ser adequado para determinados apli-
cativos especializados. Exemplos incluem aplicativos com restrições rígidas de tempo
real ou algumas operações críticas bem definidas para as quais um código customizado
eficiente deve ser escrito. Uma outra razão para não se utilizar um SGBD é que o apli-
cativo pode precisar manipular os dados de maneiras não suportadas pela linguagem
de consulta. Em tais casos, a visualização abstrata dos dados apresentada pelo SGBD
pode não corresponder às necessidades do aplicativo e realmente impossibilitar o seu
uso. Como um exemplo, os bancos de dados relacionais não suportam a análise flexível
de dados textuais (embora os fabricantes estejam atualmente estendendo seus produtos
nesta direção).
Se o desempenho especializado ou solicitações de manipulação de dados são essen-
ciais num aplicativo, pode-se optar por não utilizar um SGBD, especialmente se os
benefícios de um SGBD (por exemplo, consulta flexível, segurança, acesso concorrente
e recuperação de falha) não forem exigidos. Entretanto, na maioria das situações
em que é necessário gerenciamento de dados em grande escala, os SGBDs têm se
tornado uma ferramenta indispensável.
Encerra aqui o trecho do livro disponibilizado para
esta Unidade de Aprendizagem. Na Biblioteca Virtual
da Instituição, você encontra a obra na íntegra.
MODELAGEM E
DESENVOLVIMENTO
DE BANCO DE DADOS
Fabrício Felipe Meleto Barboza

Evolução dos bancos
de dados
Identificar a evolução dos bancos de dados.

Reconhecer a ordem cronológica dos bancos de dados.
Explicar as origens dos bancos de dados.
Introdução
Um banco de dados é um conjunto de valores e arquivos que se relacio-
nam entre si e demonstram um cadastro de pessoas, vendas, produtos,
agendas, etc. Por exemplo, uma planilha ou uma ficha cadastral podem ser
exemplos de cadastros. O banco de dados guarda todos esses cadastros
em formato virtual e os disponibiliza para as aplicações consultarem e
emitirem relatórios, realizarem vendas, etc.
Neste capítulo, você vai estudar sobre a evolução dos bancos de
dados decorrente das necessidades impostas por seus utilizadores e
para solucionar problemas da sociedade. Adicionalmente, você verá, em
uma escala de tempo, os principais marcos da história dos bancos de
dados com suas características e particularidades. Por fim, irá conhecer
o início de tudo, isto é, o que deu origem aos bancos de dados como
são conhecidos hoje em dia.
A evolução dos bancos de dados

A evolução dos bancos de dados foi e continua sendo de constante melhoria,
trazendo mais segurança e rapidez para as informações ou dados nele salvas.
Para Korth, Silberschatz e Sudarshan (2012), um banco de dados “[...] é uma
coleção de dados inter-relacionados, representando informações sobre um
domínio específico”.
Identificação interna do documento ITB70PPNV5-KNEPN9F2

2 Evolução dos bancos de dados
Pense em uma situação hipotética em que você tenha uma loja de sapatos
em um shopping. Você está verificando a implantação de um sistema para
controlar todas as suas vendas e também as compras de reposição de estoque,
de maneira que todas as informações da sua loja estarão salvas em um sistema
no computador da loja que, obviamente, utiliza um banco de dados.
Agora imagine se o vendedor do sistema pedisse pra você escolher entre 1)
um sistema rápido, que tira relatórios gigantescos em menos de um segundo,
processa vendas também em menos de um segundo do relógio, mas, por outro
lado, não garante que a informação está íntegra e consistente, e 2) um banco
de dados que garante a integridade e a consistência das informações, mas
demora dez segundos para processar alguma venda ou um minuto para criar
o relatório complexo solicitado. Qual você, dono da loja, escolheria?
Lembre-se de que a evolução em sistemas de tecnologia da informação é importante,

mas a segurança sempre deve vir em primeiro lugar para que, depois, possamos pensar
em estabilidade, funcionalidade e velocidade.
Uma tendência da evolução comum é sempre mirar e colocar o foco e as

metas em realizar a ação com mais e mais rapidez, cada vez provendo maior
velocidade e resultados instantâneos para o usuário do sistema. Porém, ao
decidir pela evolução de um sistema de banco de dados, é necessário pensar
em outros fatores além da velocidade. Com toda a certeza, a velocidade é
importante e sempre levada em consideração, mas os outros pilares precisam
ser garantidos para toda transação de um banco de dados. Esses pilares são:
Atomicidade;
Isolamento;
Consistência;
Durabilidade.
Essas quatro características são garantidas para cada transação realizada

no banco de dados, independentemente de quem realizou o comando: o próprio
sistema, o usuário final ou ainda alguma rotina automática.

Evolução dos bancos de dados 3
Mas o que seria uma transação em um sistema de banco de dados? Uma

transação para um sistema de gerenciamento de banco de dados (SGBD) é
toda e qualquer atividade que o próprio sistema de gerenciamento de banco
de dados executa após o usuário ter uma interação com o banco.
Assim, qualquer atividade provocada pelo usuário via interface do sistema
dispara uma transação ou uma cadeia de transações no banco de dados que
precisam estar garantidas e ter aderência a esses pilares. Consequentemente,
essa é a regra de ouro dos bancos de dados.
A regra de ouro dos sistemas de gerenciamento de bancos de dados é a garantia de

que todos os pilares das transações sejam assegurados e respeitados em cada uma
de suas transações internas.
Sabendo disso, agora, é necessário entender o que cada um desses pilares

representa, defende e significa para os bancos de dados.
Atomicidade
Para entender o pilar da atomicidade, fazemos uma analogia à expressão “08
ou 80”, ou seja, ou finaliza com sucesso ou tudo é abortado. Portanto, ou o
SGBD conclui todas as ações em cascata para uma transação (commit) ou ele
retorna ao estado anterior da transação (rollback).
Assim, a atomicidade é a responsável por garantir que ou uma transação
é gravada com sucesso e garantida ou é realizado o rollback de toda a transa-
ção para que o banco de dados retorne ao estado anterior daquela transação.
Nunca um sistema de gerenciamento de banco de dados pode permitir que
uma transação seja executada pela metade e fique sem rollback, pois isso faz
a consistência do banco de dados ficar quebrada.
Atomicidade é a regra do “ou tudo ou nada”. Ou toda a transação é salva com sucesso
no banco ou toda a transação é descartada.

Isolamento
Este pilar representa a independência de cada transação no sistema de gerencia-
mento de banco de dados. Cada transação é única e independente, o que faz com
que duas transações que alterem o mesmo valor de uma tabela não entrem em
conflito. Toda transação é uma engrenagem no sistema maior, que seria o SGBD.
Conforme o sistema tem mais usuários trabalhando nele, mais esta regra
se torna verdadeira e necessária. Imagine um e-commerce que realiza venda
de enfeites natalinos. Quando chegar a época de procura por esses enfeites, o
fluxo de pessoas utilizando o sistema irá aumentar consideravelmente. Agora
imagine que existe apenas um item de Papai Noel em estoque e dois clientes
realizam a compra desse item no mesmo segundo; como resolver? O pilar de
isolamento garante que a transação que for processada em primeiro lugar pelo
sistema de gerenciamento de banco de dados leve a compra e que a segunda
pessoa receba um alerta de que o produto ficou fora de estoque.
No exemplo, duas transações estavam tentando inserir dados referentes ao
mesmo valor único, que seria a quantidade de estoque do produto. Por tratar-se
de duas transações isoladas e independentes, o sistema de gerenciamento de
banco de dados rapidamente resolve essa questão, de modo que tal responsa-
bilidade não fica para a equipe de desenvolvimento.
Isolamento é a garantia de que as transações não terão disputa para edição ou escrita
em um determinado dado ou valor.
Consistência
As regras, em sua totalidade, sempre devem ser respeitadas para que o sistema
de gerenciamento de banco de dados tenha atendido suas características de
base. Isso inclui, por exemplo, que o tipo de valor inserido seja correto em
relação ao tipo do seu atributo (VARCHAR, INT, DATE, etc.).
Assim, em face da consistência, um campo do tipo Integer nunca poderá
receber caracteres alfabéticos. Essa separação se dá para a criação de buscas e
resultados mais rápidos em campos do tipo numérico. Computadores só sabem
interpretar números, de modo que campos não numéricos por natureza exigem

mais processamento do computador, que precisa transformar a informação

alfabética salva em códigos e linguagem de máquinas que são representados
por números para conseguir trabalhar.
Consistência é ter o dado certo no local esperado. Um campo do tipo Integer sempre
deverá conter um valor de número inteiro.
Durabilidade
Quando uma transação é finalizada, seus dados estão a salvo de qualquer
modificação. Somente outra transação pode modificar os dados. Assim, os
dados ficam protegidos!
Imagine que a sua compra foi finalizada com sucesso e, quando você vai buscar
seu histórico de compras, ela não aparece. Ruim, correto? A durabilidade garante
que a informação de sua compra só seja modificada por outra transação e, dessa
forma, consegue-se rastrear as requisições e buscar o que ou quem fez tal atividade.
O próprio sistema de gerenciamento de banco de dados não realiza nenhuma
modificação após a conclusão de todas as transações pendentes. Portanto,
qualquer modificação de um valor do banco de dados será de origem do
usuário ou do sistema.
Durabilidade é a proteção dos dados contra qualquer coisa que não seja uma nova
transação do banco de dados.
Cronologia dos bancos de dados

Há divergência na ordem cronológica do surgimento das versões dos bancos
de dados, exceto as versões mais comumente utilizadas. Observe a Figura 1,
que representa as etapas mais importantes da evolução dos bancos de dados.

Década de 80
Utilização de modelos em rede e hierárquico diminui
A IBM utiliza o DB2
Primeiros bancos orientados a Objeto: O2 [1988], Exodus [1986], ORION [1986]
O desenvolvimento do IBM PC ocasiona o surgimento de muitos
produtos em BD
Há a padronização do SQL pelo American National
Standards Institute (ANSI) [1986, 1989]
Figura 1. Cronograma de evolução dos BDs.

Fonte: Adaptado de Castelano [200--]; Rezende (2006).
Com base na Figura 1, percebe-se grande concentração de lançamentos e

popularização dos bancos de dados no período compreendido entre os anos
1980 até os 2000. Essa intensa movimentação se deu em virtude da infor-
matização das empresas, que aconteceu ao longo desses anos. Cada empresa
precisou incrementar seu parque tecnológico para que atendesse seus objetivos
internos, como redução de custo, melhora do valor da entrega ao cliente, ou
também objetivos externos, como estar de acordo com uma nova lei, receber
auditoria de órgãos competentes ou, ainda, pela concorrência, que está em
franca evolução e em busca por melhores resultados a todo custo.
Antes da década de 1980, temos o estágio embrionário dos bancos de dados.
Sua evolução estava ocorrendo, mas era centralizada em forma de pesquisas

e experimentos. Até porque, quando fossem apresentados para as empresas e

para o público geral, era necessário confiar no produto oferecido ao custo de
milhões de dólares em pesquisas.
Após os anos 2000, a evolução continua até os dias atuais, mas de forma
menos acelerada, já que o foco, atualmente, é em estabilidade e segurança
cada vez maiores. Partindo desse princípio, temos o surgimento de bancos
de dados NoSQL, que fazem frente aos tradicionais bancos de dados rela-
cionais SQL.
Retome a Figura 1 e atente-se para o quadrante “Anos 2000”, no qual você
verá que foi nesse período que surgiu o MongoDB, banco de dados NoSQL (Not
only SQL) e com grande poder de processamento. Aí você pode se perguntar:
“mas se ele é melhor, por que todos não migram pra ele?”. A resposta é direta:
custo e foco do projeto.
O banco de dados NoSQL não veio para matar os bancos de dados relacio-
nais como muitos imaginavam em seu lançamento, mas para complementar
e oferecer uma opção a mais para as empresas e desenvolvedores segundo
Guedes (2017).
Dessa forma, podemos exemplificar o uso de cada um dos tipos de bancos
de dados de forma mais didática: caso a aplicação tenha relacionamentos entre
as entidades e o volume de informações não for gigantesco, os bancos de dados
relacionais tradicionais atenderão muito bem a sua demanda por um sistema.
Agora, caso você tenha um sistema de bancos de dados grandioso, com
muitos valores sendo escritos e lidos ao mesmo tempo, a indicação é um banco
de dados do tipo NoSQL para que o seu sistema ganhe em desempenho e não
frustre os usuários com telas de “carregando”, erros de timeout de conexão
ou ainda a negação de serviço por falta de recursos ao processar uma consulta
gigante do gerente que trabalha remoto, impedindo de abrir a agenda de
reuniões de outro funcionário.
Lembre-se também de que, por ser uma tecnologia mais nova, o custo
para manter um banco de dados NoSQL é grande, até pela escassez de mão
de obra qualificada no mercado de trabalho. Portanto, mensure esse custo ao
tomar uma decisão sobre qual tipo de sistema de gerenciamento de bancos
de dados utilizar no projeto.
Origens dos bancos de dados

Antigamente, as empresas produziam e mantinham cadastros de tudo que
fosse necessário em fichas e papéis armazenados em um ou vários arquivos

dentro de uma ou várias salas. Portanto, cliente, fornecedor, colabora-

dor, agendas de compromisso, agendas telefônicas, inventário, controle
de estoque, etc. estavam em um papel, em algum lugar dentro de algum
arquivo.
Obviamente, organizar e manter tudo atualizado era uma tarefa complexa
demais, pois envolvia um esforço muito grande para buscar informações
básicas e que deveriam estar acessíveis para qualquer colaborador de forma
instantânea.
Imagine que é necessário buscar todos os registros de ponto de entrada
e saída de um colaborador que ficou durante vinte anos na empresa pois ele
entrou com uma ação trabalhista, por exemplo. Agora imagine essa mesma
situação e com um prazo de cinco dias para entregar toda essa informação ao
Ministério do Trabalho. Impossível, certo?
Além disso, as informações contidas nesses papéis ficavam facilmente ob-
soletas em virtude da demora em atualizar o registro. Portanto, nada confiável.
Imagine a probabilidade de um desastre na sala de arquivos, como um cano
de água rompido que encharque todos os registros da empresa. Com certeza,
a empresa em questão teria sérios problemas ou, em um caso mais extremo,
mas não descartado, até mesmo fecharia as portas se algo dessa magnitude
acontecesse.
Pode-se ir mais a fundo e imaginar que algum funcionário espião ou insa-
tisfeito com a empresa roube a informação de um projeto que iria ser lançado
no próximo ano e a venda para a concorrência. Todo o esforço empregado na
pesquisa e no desenvolvimento daquele projeto foi praticamente em vão, pois
o elemento surpresa, para pegar o mercado no ponto certo e os concorrentes
ficarem desequilibrados, foi perdido.
Sempre que um problema é detectado, ele deve ser resolvido logo por meio do
fomento de ideias para o seu contorno ou para a criação de solução definitiva.
Pense que os bancos de dados só foram inventados porque existiu uma necessidade
latente de diminuir despesas e melhorar a confiança nas informações salvas pela
empresa com o passar dos anos.

Dessa forma, havia um problema grande e generalizado em todas as cor-

porações em que registros eram feitos em papéis e armazenados em um lugar
qualquer, muitas vezes sem a devida importância para o dado, para o registro
ali contido. Como grandes problemas sugerem soluções altamente lucrativas,
iniciou-se pesquisas que apresentassem uma solução para todo esse caos vi-
venciado em cada pequeno, médio ou grande escritório ou empresa no mundo.
Na década de 1960, surge uma solução para esse caos: o banco de dados.
Vários modelos foram apresentados à IBM, financiadora do projeto, e, entre
os modelos propostos, estavam o hierárquico e o de rede.
Apesar disso, nada muito usual ou com uma viabilidade de escala foi
apresentado, o que fez os projetos serem engavetados.
Segundo Alves (2013), já na década de 1970, mais precisamente no mês
de junho, o então pesquisador da IBM Edgar Frank “Ted” Codd apresentou
um artigo que mudaria a história dos modelos de bancos de dados para
sempre – ele estava propondo o modelo relacional de bancos de dados.
Em seu artigo Relational Model of Data for Large Shared Data Banks,
Ted descrevia como usuários leigos conseguiriam extrair os dados que
lhes eram importantes.
No raciocínio de Alves (2013), vemos que, já no fim da década de 1970, surge
o Sistema R, um sistema baseado nas ideias de Ted. Junto ao lançamento do
Sistema R, veio a linguagem SQL, acrônimo para Structured Query Language,
a linguagem que dominou o mercado. O Sistema R não foi bem comercialmente
e acabou sendo abandonado, mas serviu, com toda a certeza, de inspiração e
base para muitos dos bancos de dados que temos nos dias de hoje.
Finalizando seu pensamento, Alves (2013) diz que, na década de 1980,
ocorrem dois marcos importantes na linha cronológica dos bancos de dados:
o lançamento do Oracle 2 pela própria Oracle e, também, o lançamento do
SQL/DS pela IBM, conhecido por DB2 atualmente.
Portanto, temos aí a origem dos bancos de dados. Com o passar de mais
anos e décadas, os sistemas de gerenciamento de bancos de dados foram
evoluindo segundo a necessidade dos clientes, no caso de sistemas pagos, ou
pela produção da comunidade, no caso de sistemas opensource.
Aliás, uma curiosidade que também permeia este cenário de evolução:
sempre que a comunidade dos sistemas de bancos de dados opensource lança
algo inovador, as empresas que têm bancos de dados licenciados correm atrás e
vice-versa. Com isso, muitas funcionalidades que estão presentes em sistemas
de bancos de dados opensource também se tornam presentes nos sistemas
proprietários, assim como o inverso.

A aplicação de cada sistema de banco de dados se dará pela escolha cru-

cial de quem irá desenvolver baseado no orçamento e conhecimento daquela
tecnologia de banco de dados específica para otimizar o tempo do projeto e
também o seu custo.
Lembre-se de quem fez a pesquisa para obter os bancos de dados relacionais que
conhecemos hoje: Edgar Frank “Ted” Codd, pesquisador da IBM na época e que lançou o
artigo intitulado Relational Model of Data for Large Shared Data Banks. Ted é considerado
o pai dos bancos de dados relacionais.
ALVES, G. F. O. A história dos bancos de dados. 01 abr. 2013. Disponível em: <https://dicas-
deprogramacao.com.br/a-historia-dos-bancos-de-dados/>. Acesso em: 21 maio 2018.
CASTELANO, C. R. História dos bancos de dados. [20--] Disponível em: http://castelano.
com.br/site/aulas/bd/Aula%2001%20-%20Introdu%C3%A7%C3%A3o.pdf. Acesso
em: 23 jun. 2021.
GUEDES, M. SQL vs NoSQL, qual usar? 19 jul. 2017. Disponível em: <https://www.treina-
web.com.br/blog/sql-vs-nosql-qual-usar/>. Acesso em: 21 maio 2018.
KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio
de Janeiro: Campus, 2012.Leituras recomendadas
CODD, E. F. A Relational Model of Data for Large Shared Data Banks. Communications
of the ACM, v. 13, n. 06, June 1970.
REZENDE, R. A história dos bancos de dados. 2006. Disponível em: https://www.dev-
media.com.br/a-historia-dos-banco-de-dados/1678. Acesso em: 23 jun. 2021.
REZENDE, R. Conceitos fundamentais de banco de dados. 2017. Disponível em: <https://
www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso
em: 21 maio 2018.

ADMINISTRAÇÃO
DE BANCO DE
DADOS
Márcio Motta
OBJETIVOS DE APRENDIZAGEM
• Identificar os desafios da administração de banco de dados.

• Conhecer comandos que auxiliam na administração do banco de dados.
• Reconhecer as técnicas de administração de banco de dados.
INTRODUÇÃO
O banco de dados é um dos elementos da administração de um ambiente de

informação. Para um usuário final a organização do banco de dados é invisível,
apenas aparecendo os seus resultados quando este é bem formatado
e executado. No caso de problemas, o usuário final identificará dados
inconsistentes ou problemas com a sua performance, mas não visualizando
o banco de dados em si.
Três áreas continuam a ser os maiores desafios de gerenciamento para os

administradores de banco de dados. São elas.
TECNOLOGIAS
Nos últimos anos, o surgimento de forças, como a TI híbrida, virtualização,
computação em nuvem, convergência continuada de infraestrutura e BYOD
(traga seu próprio dispositivo) ofereceram aos profissionais de tecnologia
novas formas de trabalhar, revolucionando o modelo tradicional até então
praticado na área. A expectativa é de que as pessoas que trabalham nessa
área consigam colocar em prática conceitos e tendências tecnológicas, como
bancos de dados embutidos, Internet das Coisas (IoT) e Cloud Computing, mas
sem deixar de lado as habilidades de gerenciar tecnologias e infraestruturas
tradicionais.
Cabe ao Administrador de Banco de Dados e sua equipe considerarem as

possibilidades para então definir o uso de SGBD físico ou a utilização de um
serviço na nuvem, sobre essa decisão pesarão diversos fatores que deverão ser
analisados antes de tomar uma decisão final. O mesmo vale para o tipo de SGBD
escolhido de acordo com as suas características, funções, desempenho e custos.
4
Com sua promessa de economia de custos e maior flexibilidade e agilidade,
a Nuvem está atraindo muitas organizações como uma alternativa para
a implantação de novos aplicativos, incluindo aqueles com altos requisitos
de desempenho de banco de dados. Entretanto, essa transição cria novas
complexidades e desafios para os DBAs, especialmente porque os DBAs
ainda são, em última análise, os responsáveis tanto pelo desempenho dos
bancos de dados quanto pela segurança dos dados, independentemente de
eles estarem nas próprias instalações ou na nuvem.
São algumas considerações para o gerenciamento dos dados na nuvem que

os DBAs devem ponderar antes de sua escolha:
• Ao considerar quais bancos de dados são migrados para a nuvem, levar
em conta o processo de transferência de dados e a latência, além de como
manter os bancos de dados em sincronia, se necessário, especialmente se
for preciso integrar os aplicativos com outros que não residam na mesma
implantação na nuvem.
• Um banco de dados com desempenho insatisfatório nas instalações
também apresentará um mau desempenho na nuvem. Mudar o problema de
lugar não é solução. O escalonamento na nuvem para compensar um mau
desempenho pode sair caro rapidamente, além de ser a abordagem incorreta.
• Entender os serviços e as capacidades do provedor de serviços, avaliar a
arquitetura recomendada e estar atento à manutenção programada.
• Refletir, planejar e gerencar o backup e recuperação para garantir que
dados importantes não sejam perdidos caso ocorra uma falha ou interrupção
no fornecedor.
• Mantenha-se à frente da segurança, percebendo que a criptografia é
apenas a ponta do iceberg – considere quem monitorará o acesso ao banco
de dados impedindo o acesso mal-intencionado ou não autorizado, prepare-
se para o pior e tenha um plano de ação documentado para o caso de violação
da segurança ou perda de dados.
• Se é importante monitorar e otimizar as implantações nas instalações,
isso é ainda mais importante na nuvem, dada sua natureza dinâmica, sendo
ideal usar um conjunto de ferramentas consistente em ambos os lados dos
ambientes de TI híbrida.
5
A Figura 1 a seguir procura relatar o ranking dos SGBDs mais utilizados e
traçar uma relação entre as suas tecnologias:
Figura nº 1 – Ranking dos SGBDs
Fonte: Austrian IT Consulting, disponível em: http://db-engines.com/en/

Acesso em: 28/05/2017
Nas 4 primeiras posições desse ranking são vistos 2 modelos de SGBDs de

licença proprietária (Oracle e SQL Server) e 2 de licença Open Source (Livre, de
código aberto, MySQL e MondoDB). O MondoDB vem em forte crescimento
no mercado mundial, ocupando já a quarta posição superando o também
bastante utilizado PostreSQL. Um dos motivos dessa ascensão é o fato do
MongoDB não trabalhar com o modo Relacional de tabelas como os outros
SGBDs, mas com um sistema de Índices também conhecido como NO-SQL.
PERFORMANCE
A performance do banco de dados é um fator de grandes desafios para o BDA.

O conjunto que envolve Hardware+Sistema+SGBD deve estar equacionado
para uma performance satisfatória. Porém, conforme o crescimento e a
demanda das informações armazenadas essa tarefa torna-se cadê vez
mais complexa. Muitas vezes a escolha inicial de infraestrutura pode não
ser mais suficiente, não atendendo as demandas necessárias necessitando
de migração ou atualização, ou a sua manutenção e configuração não
6
estão ocorrendo de forma organizada e coerente com as necessidades da
plataforma, causando transtornos e inconsistências.
A modelagem dos dados e a construção de consultas otimizadas são

extremamente importantes no desempenho do banco de dados. Campos mal
definidos, com tamanhos de dados equivocados tanto para textos quanto
para números são determinantes para a performance, toda a definição dos
dados (DDL) deve ser dimensionada para o tipo de dado que cada registro
receberá. O mesmo vale para a organização das consultas. Índices e
constraints (restrições) já devem ser criados na etapa de definição para que
possam ser utilizadas de forma ágil durante a manipulação dos dados(DML)
com consultas simplificadas e de resultados diretos. Muitas vezes uma
base possui milhares ou até milhões de registros, se uma consulta não for
restrita ao que se deseja, o tempo de espera poderá ser bastante demorado,
prejudicando todo o sistema.
Uma das formas de monitorar o desempenho de um SGBD (MySQL neste

exemplo) é através da ferramenta MYTOP (Linux/Open Source). Para usá-la é
necessário executar o comando:
mytop -u <usuario> -p <senha> -h <host>
Ao executá-lo, serão mostradas todas as informações dos bancos de dados

armazenados assim como os tempos de acesso e possíveis problemas, como
são apresentados na Figura 2 abaixo:
Figura nº 2 – Tela do MyTOP no Linux
Fonte: autor
7
Um erro bastante comum é se preocupar com segurança e desempenho
apenas diante da reclamação dos usuários de um dado alterado indevidamente
ou lentidão na utilização do sistema, pois um monitoramento pontual não
terá fundamento para mostrar que o banco de dados não é o culpado. É
necessário monitoramento e relatórios constantes que auxiliem o DBA a
identificar gargalos, tomando as ações necessárias preventivamente, ou
mesmo comprovando que o problema não está no banco de dados, podendo
direcionar o tratamento do problema para o local correto.
SEGURANÇA
A preocupação com a criação e manutenção de ambientes seguros se tornou

a ocupação principal de administradores de redes, de sistemas operacionais
e de bancos de dados. Pesquisas mostram que a maioria dos ataques,
roubos de informações e acessos não- autorizados são feitos por pessoas
que pertencentes à organização alvo. De modo geral, os mecanismos de
segurança referem-se às regras impostas pelo subsistema de segurança do
SGBD, que verifica todas as solicitações de acesso, comparando-as com as
restrições de segurança armazenadas no catálogo do sistema. Entretanto
existem brechas no sistema e ameaças externas que podem resultar em um
servidor de banco de dados comprometido ou na possibilidade de destruição
ou no roubo de dados confidenciais.
As ameaças aos bancos de dados podem resultar na perda ou degradação de

alguns ou de todos os objetivos de segurança aceitos, são eles: integridade,
disponibilidade, confidencialidade. A integridade do banco de dados se refere
ao requisito de que a informação seja protegida contra modificação imprópria.
Os bancos de dados SQL implementam mecanismos que restringem ou
permitem acessos aos dados de acordo com papeis ou roles fornecidos
pelo administrador. O comando GRANT concede privilégios específicos para
um objeto (tabela, visão, seqüência, banco de dados, função, linguagem
procedural, esquema ou espaço de tabelas) para um ou mais usuários ou
grupos de usuários.
São tipos de controles que podem ser implementados para garantir maior
segurança nos bancos de dados:
8
Controle de Acesso
É todo controle feito quanto ao acesso ao BD, impondo regras de restrição,
através das contas dos usuários. O DBA é o responsável superior por declarar
as regras dentro do SGBD. Ele é o responsável por conceder ou remover
privilégios, criar ou excluir usuários, e atribuição de um nível de segurança
aos usuários do sistema, de acordo com a política da empresa.
Controle de Inferência
É um mecanismo de segurança para banco de dados estatísticos que atua
protegendo informações estatísticas de um individuo ou de um grupo. Bancos
de dados estatísticos são usados principalmente para produzir estatísticas
sobre várias populações. O banco de dados pode conter informações
confidenciais sobre indivíduos. Os usuários têm permissão apenas para
recuperar informações estatísticas sobre populações e não para recuperar
dados individuais, como, por exemplo, a renda de uma pessoa específica.
Controle de Fluxo
É um mecanismo que previne que as informações fluam por canais secretos
e violem a política de segurança ao alcançarem usuários não autorizados.
Ele regula a distribuição ou fluxo de informação entre objetos acessíveis. Um
fluxo entre o objeto A e o objeto B ocorre quando um programa lê valores de
A e escreve valores em B. Os controles de fluxo têm a finalidade de verificar se
informações contidas em alguns objetos não fluem explicita ou implicitamente
para objetos de menor proteção. Dessa maneira, um usuário não pode obter
indiretamente em B aquilo que ele ou ela não puder obter diretamente de A.
Criptografia de Dados
Você pode ler aqui um pouco mais sobre criptografia. É uma medida de
controle final, utilizada para proteger dados sigilosos que são transmitidos
por meio de algum tipo de rede de comunicação. Ela também pode ser
usada para oferecer proteção adicional para que partes confidenciais de um
banco de dados não sejam acessadas por usuários não autorizados. Para
isso, os dados são codificados através da utilização de algum algoritmo de
codificação. Assim, um usuário não autorizado terá dificuldade para decifrá-
los, mas os usuários autorizados receberão chaves para decifrar esses dados.
A criptografia permite o disfarceda mensagem para que, mesmo com o desvio
da transmissão, a mensagem não seja revelada.
9
Privilégios
Os privilégios são permissões únicas dadas a cada usuário ou grupo. Eles
definem permissões para tipos de autorização. Pelos privilégios é possível
autorizar o usuário a modificar ou alcançar determinado recurso do Banco de
Dados.
O SGBD deve oferecer acesso seletivo a cada relação do banco de dados

baseando-se em contas específicas. As operações também podem ser
controladas; assim, possuir uma conta não necessariamente habilita o
possuidor a todas as funcionalidades oferecidas pelo SGBD. Informalmente
existem dois níveis para a atribuição de privilégios para o uso do sistema de
banco de dados:
• Nível de conta: Nesse nível, o DBA estabelece os privilégios

específicos que cada conta tem, independente das relações no banco
de dados.
• Nível de relação (ou tabela): Nesse nível, o DBA pode controlar o
privilégio para acessar cada relação ou visão individual no banco de
dados.
Em alguns casos, interessa conceder um privilégio temporário a um usuário.

Por exemplo, o proprietário de uma relação pode querer conceder o privilégio
SELECT a um usuário para uma tarefa específica e depois revogar aquele
privilégio quando a tarefa estiver completada. Por isso, é necessário um
mecanismo para a revogação de privilégios. Em SQL, um comando REVOKE é
introduzido com o intento de cancelar privilégios.
10
REFERÊNCIAS
Embarcadero - Database Trends Survey Report. Disponível em: http://www.

embarcadero.com/images/dm/technical-papers/database-survey-report.
pdf. Acessado em: 28 de maio de 2017.
PFLEEGER, Charles P.; PFLEEGER, Shari L. - Security in computing. 4ª ed.

Massachusetts: Editora Prentice Hall, 2012.
SHASHA, DENNIS, BONNET, PHILIPPE - Database Tuning, Morgan Kaufmann

Publishers, 2003.
11
MODELAGEM E
DESENVOLVIMENTO
DE BANCO DE
DADOS
Fabrício Felipe
Meleto Barboza
Conceitos de banco
de dados
Identificar a importância da utilização do banco de dados no contexto

organizacional.
Reconhecer as principais ferramentas de administração de banco
de dados.
Relacionar os principais ambientes de banco de dados.
Introdução
Neste capítulo, você vai estudar a necessidade do uso de banco de dados
no lugar de outra forma de guardar as informações, como, por exemplo,
planilhas eletrônicas ou documentos de textos.
Adicionalmente, você também conseguirá vislumbrar a diferença
entre os sistemas de bancos de dados existentes atualmente, suas apli-
cações mais comumente utilizadas nas corporações em geral e, também,
os aspectos positivos e negativos de cada opção de uso dos sistemas
abordados.
Necessidade de uso dos bancos de dados

Imagine que você trabalha em uma pequena loja que tem como principal
fonte de receita a comercialização de capinhas de celulares. A cada entrada
de mercadoria no estoque ou baixa ao realizar uma venda, é registrada a
respectiva ação em um caderno de registros. Tome por base que essa lojinha
venda uma capinha de celular por dia: ao longo de um mês, haverá 30 registros
de venda e de 2 a 3 registros de entrada de mercadoria. Bem fácil controlar
na caderneta, certo?
2 Conceitos de banco de dados
Mas então o dono da lojinha recebeu uma herança e resolveu comprar um

espaço no shopping mais movimentado da cidade para expandir os negócios.
De 30 capinhas ao mês, agora a venda aumentou para três mil capinhas. O seu
trabalho de registro na caderneta começou a ficar complexo e a tomar cada
vez mais tempo do seu dia. Para resolver o problema, um sobrinho do dono
da loja fez uma planilha eletrônica linda, cheia de fórmulas e que resolve mais
rapidamente seu problema de cadastro.
Como um excelente homem de negócios, seu chefe resolveu abrir 20 filiais
novas. Temos, então, 60 mil registros de venda de capinhas mais os registros
de entrada de estoque por mês. Se colocarmos que a quantidade de linhas
que uma planilha eletrônica suporta atualmente é cerca de um milhão, você
iria enchê-la em menos de 18 meses (ou um ano e meio). Além disso, essa
planilha ocuparia muito espaço no computador e você levaria muito tempo
para recuperar as informações inseridas ali em cada momento de venda.
Então você se cansa de trabalhar nessa loja, entra em uma empresa de tele-
fonia multinacional e se pega imaginando quantas planilhas eles possuem para
controlar todas as ligações que seus clientes fazem a cada minuto. Segundo a
ANATEL (BRASIL, 2018), a quantidade de linhas telefônicas fixas no Brasil já
passou a marca de 40 milhões e meio. Coloque nessa equação a quantidade de
linhas telefônicas móveis (celulares) e temos o caos das planilhas eletrônicas.
A solução para qualquer um dos casos apresentados, desde a lojinha que
vendia 30 capinhas de celular por mês até a grande companhia telefônica com
milhões de novos registros que precisam ser processados a cada segundo, é
uma só: banco de dados.
Acesse o link a seguir e leia a notícia da ANATEL, que apresenta a enorme quantidade
de linhas fixas existentes em todos os estados brasileiros.
https://goo.gl/6wcb8D
Da mesma forma, a atividade pertinente a qualquer área de uma organização

requer um poder grande de armazenamento de informações, ordenação, busca
e edição. Pense em um sistema on-line popular qualquer, como, por exemplo, o
Conceitos de banco de dados 3
Facebook. Inúmeros bancos de dados são utilizados para prover a plataforma

da rede social, cada qual com seu objetivo: um banco de dados somente para
o cadastro dos usuários, outro banco de dados para as postagens dos usuários,
um terceiro banco de dados para armazenar as fotos dos usuários, mais outro
banco de dados para o feed de notícias, um quinto banco de dados para o chat
da plataforma, etc.
Cada sistema tem sua própria divisão de banco de dados, mas você pode
ter certeza de que é necessário um ou mais banco de dados para suportar um
blog, por mais simplista que possa parecer — até mesmo para grandes plata-
formas, como Facebook, LinkedIn, Instagram, WhatsApp, Twitter, sistemas
bancários e demais sistemas.
Quando você efetua a compra de um produto qualquer para o qual é
emitida uma nota fiscal eletrônica, o fluxo de funcionamento daquele ponto
de venda (PDV) com a ação do colaborador do estabelecimento ao registrar
seu CPF na nota, por exemplo, seria o que está visualmente representado
na Figura 1.
Vendedor realiza a venda e insere o CPF

do comprador no sistema da loja
O sistema de banco de dados
da loja:
1. Baixa a quantidade vendida
2. Verifica se atingiu o limite
mínimo de estoque e alerta O banco de dados da Receita Estadual
o gerente ou Federal recebe a solicitação de
3. Conclui a venda e envia emissão de nota e:
sinal para emissão da nota fiscal 1. Confere se o sistema da loja está apto
a realizar a venda
2. Pega a informação do CPF informado
e consulta se é válido
3. Realiza os cálculos de impostos em
cima da venda para a exibição no cupom
O banco de dados do sistema fiscal
de CPF na nota: 4. Cadastra a nota/cupom fiscal na base
1. Recebe a emissão da nova de dados
nota e grava no banco de dados 5. Informa o sistema CPF na nota desta
2. Calcula o valor de retorno de nova compra daquele CPF
crédito para o consumidor
3. Disponibiliza a consulta desse
crédito no seu sistema on-line
4. Caso tenha, insere cupons para
participar de sorteios de prêmios
Figura 1. Fluxo de relações entre banco de dados.
Sendo assim, com a utilização de banco de dados, tanto o cadastro de novos

registros, como a venda de uma capinha de celular do exemplo anterior, quanto
uma nova ligação por parte do cliente da grande companhia telefônica resulta
em um novo registro no próprio banco de dados — portanto, uma nova linha
da “planilha”. Como os bancos de dados, em sua maioria, estão conectados aos
sistemas, esse registro é feito de forma automática e é garantida a integridade
da informação.
Imagine o sistema de uma loja virtual ou sites de compra e venda. O relacionamento

entre bancos de dados ocorre por segundo, muitas vezes, para o envio, troca, edição,
exclusão e informe de operações. Sites como o do Mercado Livre, por exemplo, precisam
de um banco de dados robusto e confiável.
Como administrar um banco de dados

A questão da administração de um banco de dados é ampla e complexa, sendo
debatida por diversos autores. Em resumo, você deve ter conhecimento de
que tipo de informação está alocada nas tabelas do seu banco de dados e,
principalmente, como manipular as informações que ali estão inseridas da
forma que necessita.
Um sistema de banco de dados é formado pelo software de banco de dados,
o repositório de tabelas denominado database e as próprias tabelas em si ou
tables. Dessa forma, um banco de dados para um sistema de agenda telefônica
teria o serviço do banco de dados executado, uma database e, dentro desta,
estariam as tabelas para gravar as informações de nome, endereço, contato
telefônico, e-mail, aniversário, foto, etc.
Portanto, para você conseguir realizar uma boa administração do banco
de dados, é necessário conhecer o negócio ou o projeto ao qual ele servirá.
De nada adianta ter tabelas que não são necessárias, pois isso impacta na
performance do serviço. No exemplo da agenda telefônica, se não existisse
o campo “contato telefônico”, o sistema ficaria inútil, pois uma agenda tele-
fônica precisa, obrigatoriamente, conter o campo para cadastro do telefone
do contato.
No exemplo da agenda telefônica, existem campos obrigatórios e campos opcionais.

Os campos “nome” e “contato telefônico” são obrigatórios. Já os campos “endereço”,
“e-mail”, “aniversário” e “foto” são opcionais.
Essa diferenciação se deve ao fato de que uma agenda telefônica precisa, no mínimo,
gravar o nome e o telefone de contato da pessoa. Portanto, o banco deve respeitar
essa regra para ser bem construído.
Como passo fundamental na administração correta de um banco de dados,

é essencial que você tenha a documentação base do sistema que utilizará
do banco de dados sob sua administração. Esse documento contemplará a
modelagem do banco de dados, os relacionamentos entre tabelas, como será
gravada cada informação, quais campos são obrigatórios e quais são opcionais,
a necessidade de indexação para melhorar a velocidade de consulta, etc.
A seguir, na Figura 2, você verá um exemplo simples de uma modelagem
de banco de dados, na forma de entidade-relacionamento, para compreensão.
Essa forma de ilustração do banco de dados é a mais comumente utilizada em
documentações e projetos. Nela, cada retângulo representa uma tabela, cujo
título é o seu nome. Para cada tabela, há uma relação de atributos (linhas abaixo
do título) e linhas ligando essas tabelas, que representam os relacionamentos
entre elas. Por ora, você precisa atentar para o nome e cada atributo das tabelas a
seguir, pois iremos estudar esse e outros modelos de banco de dados mais adiante.
Cliente
Nome
Telefone
Produto
Endereço Código
Cidade Nome
Estado Preço
CPF Qtd Estoque
Venda
Código
CPF_Cliente
Código_produto
Data
Valor
Código_nfe
Figura 2. Exemplo de banco de dados.

Note que existem três tabelas ou tables no banco de dados da Figura 2: tabela
“Cliente”, tabela “Produto” e tabela “Venda”. O relacionamento entre elas é
executado quando o colaborador registra uma venda; então, o banco de dados
cria um registro na tabela “venda” contendo os dados do produto comprado
e os do cliente que comprou. Cada tabela tem atributos próprios, que seriam
suas colunas, nas quais ficam as informações correspondentes. Ou seja, pela
tabela “Cliente” foi mapeado que o cadastro de cliente terá os campos “Nome”,
“Telefone”, “Endereço”, “Cidade”, “Estado” e “CPF”. Já na tabela “Produto”, os
atributos (colunas) são “Código”, “Nome”, “Preço” e “Quantidade Estoque”. Por
fim, temos a tabela “Venda” com os atributos (colunas) “Código”, “CPF_cliente”,
“Código_produto”, “Data”, “Valor” e “Código_nfe”.
Para otimizar a quantidade de registros no banco de dados, existe a chave
primária e a chave estrangeira. A chave primária é um campo que é definido
como único e não pode repetir-se naquela tabela. Como exemplo de chave
primária para a tabela “Cliente”, pode-se utilizar o CPF, que é um número
único por pessoa (ninguém no Brasil tem o mesmo CPF que o seu). Para a
tabela “Produto”, foi criado um atributo chamado “Código”. Já a tabela “Venda”
pode usar o seu campo “Código”.
A chave estrangeira ocorre quando pegamos um atributo de outra tabela
que é chave primária nela. Veja novamente a Figura 2 e observe que, na tabela
“Venda”, existem duas possíveis chaves estrangeiras: “CPF_cliente”, que
vem da tabela “Cliente”, e “Código_produto”, que vem da tabela “Produto”.
Isso se dá para que, quando alguém pedir relatório de vendas, ao consultar a
tabela “Venda”, o sistema consiga buscar, por meio do campo “CPF_cliente”,
os dados do cliente na tabela “Cliente” e os dados do produto por meio do
campo “Código_produto” na tabela “Produto”.
A dúvida que surge é a de por que realizar esses relacionamentos e não
simplesmente criar mais atributos na tabela “Venda” para comportar os dados
do cliente e dos produtos nessa própria tabela. A resposta é bem simples: em
bancos de dados, assim como em qualquer sistema tecnológico, os dados têm
complexidade e, quanto mais dados, maior a complexidade para processá-
-los. Ao registrar apenas o código do produto e o CPF do cliente e, com
isso, realizar a busca nas tabelas correspondentes de “Cliente” e “Produto”,
você está otimizando recursos computacionais e mantendo o banco de dados
totalmente escalável.
Imagine que podem existir milhões de vendas diárias, de maneira que você
pouparia muito processamento ao identificar as vendas apenas com os códigos
das demais tabelas e, caso necessário, poderia recuperar a informação dessas
tabelas em um relatório para o gerente da loja, por exemplo. Outra vantagem é
que, ao fazer uma atualização cadastral de um cliente (telefone, por exemplo),

você teria que sair varrendo a tabela de “Venda” também, caso ela tivesse os
campos replicados da tabela “Cliente”.
Geralmente, a modelagem de banco de dados ocorre em times, como forma
de ser o mais acertado possível, visto que um retrabalho em cima da mode-
lagem é muito mais oneroso do que se já estiver correto no início do projeto.
Quando um sistema se torna grande, essa modelagem apresentará centenas
de tabelas e milhares de atributos e relacionamentos entre elas. A seguir, na
Figura 3, observe o exemplo de um sistema de clínica veterinária com maior
número de tabelas, atributos e relacionamentos:
Figura 3. Modelagem entidade-relacionamento.

Fonte: Imgur (2018, documento on-line).
Observe que, na Figura 3, aparecem novas informações após o nome do

campo, como varchar, integer, date, time, bool, etc. Essas informações se refe-
rem ao tipo de dado que a coluna relacionada poderá receber. Então, seguindo
esse raciocínio, a tabela “Animal”, no atributo “dtNascimento”, que é do tipo
DATE, só poderá receber o valor de data válido. Qualquer coisa diferente disso
será descartada pelo próprio banco de dados, que não permitirá a inserção.
Outro exemplo: na tabela “Cliente”, o atributo “nrCEP” é do tipo INTEGER,
de modo que só aceitará caracteres do tipo inteiro e, novamente, caso a entrada
seja diferente de 0 até 9, o próprio banco de dados proíbe a entrada.
Pode-se concluir, então, uma relação de tipos de atributos mais comumente

utilizados nos bancos de dados atualmente:
INT ou INTEGER: recebe apenas números inteiros. Exemplo: 45002.

VARCHAR: recebe caracteres alfanuméricos. Exemplo: João da Silva.
DATE: recebe apenas datas válidas. Exemplo: 01/01/2018.
TIME: recebe apenas valores expressos em hora. Exemplo: 16:54.
BOOL ou BOOLEAN: recebe apenas o número 0 ou o número 1. Serve
para indicar se algo é verdadeiro ou falso, positivo ou negativo, etc.
Exemplo: 0 (o sistema sabe que, se esse campo for 0, o cliente está
verdadeiro para compra a prazo).
Exemplos de sistemas de banco de dados e seus

usos na prática
Com toda essa introdução sobre os sistemas de banco de dados, vamos abordar,
agora, quais são os tipos de bancos de dados disponíveis e suas características
e usos pelos diversos tipos de aplicações e corporações.
Nos dias atuais, quatro sistemas de banco de dados dominam o cenário
geral e um quinto está em franco crescimento. São eles:
MySQL;
MariaDB;
Microsoft SQLServer;
PostgreSQL;
Oracle;
MongoDB (franca expansão).
Linguagem SQL
Para realizar a inserção, remoção, edição ou qualquer outra atividade com
os dados que irão ou estão no banco de dados, é necessária uma interação
com o mesmo. Dessa forma, a linguagem SQL (Structure Query Language
ou Linguagem de Consulta Estruturada) é a que intermedeia essa interação,
criando a ponte necessária entre o que precisa ser feito e o banco de dados
efetivamente. Assim, para que algo aconteça, é necessário que a linguagem
SQL esteja com a sintaxe correta e os valores desejados também corretos.
Aplicada para gerenciar os bancos de dados do tipo MariaDB (e MySQL),

Microsoft SQLServer, PostgreSQL e Oracle, é a linguagem comumente usada
por database administrators diariamente em suas jornadas de trabalho.
Perceba que o MongoDB, quinto item da lista anterior e marcado como
em franca expansão, não utiliza a linguagem SQL para criar suas consultas e
manipular os dados necessários. Isso se dá pela forma com que ele organiza
suas informações e também como disponibiliza as mesmas de volta ao sis-
tema quando este solicita uma consulta, por exemplo. Assim, ele consegue
desempenhar uma velocidade incrível de resposta a consultas se comparado
aos bancos de dados mais tradicionais que utilizam a linguagem de consulta
estruturada (SQL). Portanto, o MongoDB é um banco de dados do tipo não
relacional.
Segundo Elmasri e Navathe (2007), a linguagem SQL nasceu unicamente
para ser a linguagem de consulta do sistema System R da IBM. A evolução
desta empresa originou a linguagem SQL tão difundida atualmente.
A linguagem SQL tem uma sintaxe bem estruturada. Um exemplo básico seria:
SELECT atributos (obrigatório);
FROM tabelas (obrigatório);
WHERE condições (opcional).
Assim, para retornar o nome e CPF de todos os clientes que moram no Paraná
cadastrados na tabela “Cliente” da Figura 2, faríamos:
SELECT Nome, CPF;
FROM Cliente;
WHERE Estado = PR.
Uma resposta para por que a linguagem SQL é tão utilizada e difundida
em todo o mundo pode ser compreendida como:
A linguagem possui muitos recursos, tanto para manipulação de dados (DML,

Data Manipulation Language) como para a definição de dados (DDL, Data
Definition Language). Por conta disso, SQL é a linguagem mais utilizada em
sistemas de bancos de dados (KOMATSU, 2011, p. 20).
Tipos de bancos de dados

A grande maioria dos projetos envolvendo bancos de dados toma por base a
questão custo x benefício, ainda mais nos tempos atuais, em que as corporações
necessitam de diminuição constante dos valores despendidos em qualquer
área. Assim, de início, dividimos a lista dos bancos de dados em duas grandes
frentes: os bancos de dados que precisam de uma licença paga e os bancos de
dados que não necessitam de uma licença de uso paga.
Quadro 1. Relação de licenças x custo de administração
Custo do
Tipo de administrador Tamanho do
Banco de dados licença do database projeto
MySQL Paga Baixo Pequeno a médio
MariaDB Gratuita Baixo Pequeno a médio
Microsoft SQLServer Paga Alto Médio a grande

Standard ou Enterprise
Microsfot SQLServer Gratuita Médio Pequeno

Express
PostgreSQL Gratuita Médio Médio a grande
Oracle Paga Alto Grande
MongoDB Gratuita Alto Médio a grande
Com base nas informações apresentadas no Quadro 1, podemos refletir

sobre a necessidade do projeto que precisa ser desenvolvido diante da realidade
de custos sucintamente apresentados nessa mesma tabela informativa. Quanto
maior o projeto, mais robusto precisa ser o banco de dados e, por consequência,
mais cara será a cobrança por parte de quem o administra.
BRASIL. Agência Nacional de Telecomunicações. Brasil encerrou o mês de março com

40,46 milhões linhas fixas em serviço. 08 maio 2018. Disponível em: <www.anatel.gov.
br/dados/destaque-1/331-brasil-tem-40-55-milhoes-linhas-fixas-em-operacao-no-
-mes-de-fevereiro>. Acesso em: 09 maio 2018.
ELMASRI, R.; NAVATHE, S. B. Fundamentals of database systems. 4. ed. London: Pearson
Education, 2007.
IMGUR. [Modelagem relacionamento]. 2018. Disponível em: <https://i.stack.imgur.
com/Y8FiZ.png>. Acesso em: 18 maio 2018.
KOMATSU, A. S. V. Interpretador de linguagens de consulta relacionais. 2011. 44 f. Trabalho
de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade de
São Paulo, São Paulo, 2011. Disponível em: <https://bcc.ime.usp.br/tccs/2011/andre-
suzuki/monografia.pdf>. Acesso em: 09 maio 2018.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2008. (Série
Livros Didáticos Informática UFRGS, v. 4).
KORT, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistemas de bancos de dados. 6. ed. Rio
de Janeiro: Campus, 2012.
Conteúdo:
MODELAGEM E
DESENVOLVIMENTO
DE BANCO DE DADOS
Fabrício Felipe Meleto Barboza

Tipos de bancos de dados
Identificar os vários tipos de bancos de dados.

Reconhecer os tipos de bancos de dados pela sua sintaxe.
Relacionar os bancos de dados com os vários tipos existentes.
Introdução
Neste capítulo, você vai estudar sobre como identificar e reconhecer os
diversos tipos de bancos de dados pela sua sintaxe. Assim, será capaz de
reconhecer os padrões de cada sintaxe e identificar o banco de dados
associado. Você verá exemplos de uso e os diferentes padrões em cada
um dos bancos de dados: PostgreSQL, Microsoft SQL Server, MySQL/
MariaDB e Oracle. Adicionalmente, verá como relacionar os bancos de
dados em função dos vários tipos existentes atualmente.
Os vários tipos de bancos de dados

Vamos relembrar o conceito de bancos de dados? Segundo Korth, Silbers-
chatz e Sudarshan (2012), banco de dados “[...] é uma coleção de dados inter-
-relacionados, representando informações sobre um domínio específico”.
Dessa forma, estudaremos, neste capítulo, os diversos tipos de bancos de
dados mais comumente utilizados e conhecidos atualmente, limitando-nos às
quatro primeiras posições desse mesmo ranking de utilização.
Usualmente, as empresas utilizam um dos quatro bancos de dados a seguir
em suas aplicações, sistemas ou projetos:
MySQL/MariaDB;
Oracle;
Microsoft SQL Server;
PostgreSQL.
2 Tipos de bancos de dados
Analisaremos cada um desses bancos de dados, abordando sua origem,

plataforma compatível, características únicas e escopo de trabalho.
MySQL/MariaDB
O MySQL foi inserido junto ao MariaDB em virtude deste segundo ser
um fork do primeiro, tendo estrutura e comandos bem semelhantes e de
funcionamento idêntico. O MySQL era um banco de dados opensource
até a sua compra pela Oracle em 2009. Esse paralelismo é tão grande e
forte que os próprios administradores de bancos de dados do MySQL
conseguem, de forma bem fácil, gerenciar um banco de dados do tipo
MariaDB e vice-versa.
Fork significa uma bifurcação. Portanto, o MariaDB ser um fork do MySQL quer dizer
que o MySQL teve uma bifurcação em sua história que originou o MariaDB.
A instalação de um banco de dados do tipo MySQL ou MariaDB pode

ser realizada tanto em sistema operacional Linux nas distribuições CentOS,
RedHat, Ubuntu, Debian ou Fedora quanto no Windows.
Lembre-se que o banco de dados MySQL é quase que totalmente compatível com
o MariaDB exatamente porque o MariaDB é um fork do MySQL. Um dos criadores
originais do MySQL desenvolveu o MariaDB.
Até mesmo a forma de abrir e realizar uma conexão ao banco de dados

é semelhante entre o MySQL e o MariaDB. Outra característica curiosa é a
semelhança entre os dois logotipos que representam cada um destes bancos
de dados (Figura 1).
Tipos de bancos de dados 3
Figura 1. Logos do MySQL (a) e do MariaDB.

Fonte: MySQL (2018, documento on-line) e MariaDB
Repare que ambos os animais presentes nos logotipos fazem parte do

ambiente marinho: um golfinho para o MySQL e uma foca para o MariaDB. O
licenciamento do MySQL é pago e o MariaDB veio para suprir a comunidade
opensource e, assim, não ter custo pelo licenciamento do banco de dados.
Sua grande disseminação se dá em virtude de diversos sistemas e linguagens
de programação terem uma fácil e rápida conexão com ele. Como linguagens,
destacam-se o PHP e Python. Já para os sistemas, temos Wordpress e Magento.
Oracle
A gigante de tecnologia Oracle possui um banco de dados de mesmo nome e
que é um dos bancos de dados mais utilizados do mundo.
Um dos maiores salários dos profissionais de tecnologia da informação é o dos admi-

nistradores do banco de dados Oracle.
Seu lançamento ocorreu em 1980 e ele domina o mercado desde então. É

um banco de dados do tipo relacional, tem uma base confiável e robusta, e é
muito utilizado para projetos muito grandes, com várias transações ocorrendo
em um mesmo segundo, tanto de leitura quanto de escrita, além de uma
incrível performance.
Como seu licenciamento é pago e a cifra gira em um valor muito alto,

na casa de cinco ou seis dígitos, as empresas que o utilizam são de porte
médio para grande em função do alto custo — além do já mencionado custo
diferenciado pelo profissional que o administra.
A Oracle, exatamente por saber de seu diferencial competitivo no mercado,
lançou diversas certificações para capacitar o profissional que irá trabalhar
com o seu sistema de banco de dados. Essas certificações também atestam,
para a empresa contratante, o conhecimento e a experiência do profissional
em questão. Conforme lembra Almeida (2018), os demais sistemas de bancos
de dados também possuem certificação, mas a trilha de certificação da Oracle
é a mais estruturada e reconhecida no mercado de trabalho exatamente pela
importância do banco de dados em questão. O banco de dados Oracle é ins-
talado em sistemas operacionais Linux e também em sistemas operacionais
Microsoft Windows.
Microsoft SQL Server

A gigante de Redmond lançou o seu banco de dados em 1989 e vem evoluindo
esse banco desde então. Um limitador do sucesso do Microsoft SQL Server é
que, até pouco tempo atrás, só era possível instalá-lo em sistema operacional
Windows, deixando toda a comunidade que trabalha com opensource Linux
sem a possibilidade de usá-lo. Eis que a Microsoft, em 2017, lançou uma versão
do banco de dados para Linux de forma a reverter a situação e alavancar seu uso.
Como o Oracle, o Microsoft SQL Server tem o seu licenciamento na mo-
dalidade paga. O grande trunfo do Microsoft SQL Server é a sua aproximação
da linguagem .NET e, também, seus desenvolvedores.
PostgreSQL
Outro banco de dados de licenciamento livre é o PostgreSQL. Ele é do tipo
relacional e foi lançado em 1989 pela PostgreSQL Global Development Group.
O PostgreSQL, assim como o MySQL e o MariaDB, tem forte apelo para
aplicações WEB de pequeno e médio porte. Grande parte dos sites e sistemas
do tipo WEB utilizam um banco de dados PostgreSQL para armazenamento
dos dados.
Diversos sistemas operacionais são suportados pelo PostgreSQL (Figura 2),
sendo tanto Linux quanto o Microsoft Windows. Dessa forma, seu concorrente
no mundo dos bancos de dados acaba sendo, por eliminação e proximidade,
o MariaDB.
Seu logo é composto pela representação da cabeça de um elefante, reme-

tendo à lendária ideia de que um elefante nunca se esquece do que ou quem
ele visualizou.
Figura 2. Logo do PostgreSQL.

Fonte: PostgreSQL (2018, documento on-line).
Os tipos de bancos de dados e sua sintaxe

Para facilitar o seu entendimento, serão disponibilizados exemplos de inser-
ção, edição e deleção de um dado. Esses comandos podem ser utilizados em
qualquer um dos bancos de dados MySQL, MariaDB, Oracle, Microsoft SQL
Server ou PostgreSQL.
Como complemento e para diferenciar os bancos, também serão de-
monstrados os comandos particulares de cada banco de dados para exibir
todos os databases e o comando para mostrar todas as tabelas de um
database. Esses comandos serão exemplificados nos quatro bancos de
dados descritos no parágrafo anterior. Para a inserção de dados, é utilizada
a sintaxe a seguir.
Exemplificando em um insert na tabela “cliente” o cadastro de José da

Silva, podemos usar algo semelhante a:
Já para a edição de dados, é utilizada a sintaxe a seguir:
Exemplificando em uma edição da tabela “cliente” e no cadastro de José da

Silva, modificando seu número de telefone, podemos usar algo semelhante a:
Para a exclusão de dados, é utilizada a sintaxe a seguir:
Exemplificando a deleção com o cadastro de José da Silva da tabela

“cliente”, podemos usar algo semelhante a:
Portanto, os comandos apresentados anteriormente podem ser utilizados

em qualquer um dos quatro bancos de dados estudados aqui: MySQL ou
MariaDB, Oracle, Microsoft SQL Server ou, por último, mas não menos
importante, o PostgreSQL.
Os comandos de exibir os databases ou exibir as tabelas são particulares
para cada banco de dados e, dessa forma, foram separados. A seguir, são
apresentados cada um deles.
MySQL/MariaDB
A sintaxe do MySQL é praticamente idêntica ao MariaDB exatamente pelo
fato deste segundo ser um fork do primeiro.
Para exibir todas os databases no MySQL ou no MariaDB, utiliza-se:
O retorno do comando será o nome de todos os databases contidas no banco

de dados independentemente de ter, ou não, tabelas, um database por linha.
Já para exibir todas as tabelas de um database, primeiro é necessário fazer
a seleção do database desejada:
Após a seleção do database, pode-se realizar a consulta das tabelas com

o comando:
O retorno desse comando será uma listagem de todas as tabelas daquele

database selecionada previamente, uma tabela por linha.
Oracle
Para o Oracle, os comandos de exibição são diferentes do MySQL ou do
MariaDB. Caso precise exibir todos os databases, você pode usar o comando:
Novamente, o retorno do comando será o nome de todos os databases

contidos no banco de dados independentemente de ter ou não tabelas, um
database por linha. Se a necessidade é exibir todas as tabelas de um database,
antes de executar o comando necessário para conseguir o resultado esperado,
é preciso selecionar o schema desejado:
Após isso, rode o comando a seguir para exibir as tabelas:
Microsoft SQL Server

Para que o Microsoft SQL Server liste os databases, é necessário fazer a
consulta de forma um pouco diferente dos demais bancos:
Caso não queria que o retorno inclua os databases do sistema, ou seja,

que exiba somente os databases que foram criados, pode-se usar o comando:
Já para listar as tabelas de um database, é necessário escolher um database

com o comando:
Após o comando de escolha do database, execute o comando para realizar

a consulta de todas as tabelas daquele database:
Perceba que o Microsoft SQL Server é menos preparado para trazer esse
tipo de informação de database ou tabela se comparado aos demais bancos
de dados.
PostgreSQL
Exibir todos os databases no PostgreSQL é bem simples. Basta digitar:
O retorno do comando será o nome de todos os databases contidos no

banco de dados independentemente de ter, ou não, tabelas, um database por
linha. Já para exibir todas as tabelas de um database, primeiro é necessário
fazer a seleção do database desejada com o comando:
Após a seleção do database, pode-se realizar a consulta das tabelas com

o comando:
O retorno desse comando será uma listagem de todas as tabelas daquele
database selecionado previamente, uma tabela por linha.
Relação entre os bancos de dados

A relação entre os bancos de dados que utilizam a linguagem SQL para con-
sultas é idêntica para o trabalho de manipulação dos dados envolvidos, seja o
comando de INSERT, UPDATE ou até mesmo o DELETE.
Partindo dessa premissa e também pelo que explica Gomes (2018), a di-
ferenciação entre os bancos de dados, mesmo os que utilizam a linguagem
SQL, ocorre no âmbito de gerenciamento desses bancos, seja na consulta aos
nomes de databases que o mesmo possui ou ainda na listagem do nome das
tabelas (Quadro 1).
Quadro 1. Relação de banco de dados que utilizam a linguagem SQL
Banco de dados Tipo Exibir os databases
MySQL / MariaDB SQL Show databases;
Microsoft SQL SQL SELECT [name] FROM master.

Server dbo.sysdatabases;
Oracle SQL/NoSQL SELECT NAME FROM v$database;
PostgreSQL SQL \list
MongoDB NoSQL show dbs;
Lembre-se de que os bancos de dados que utilizam a linguagem SQL para realizar a
manipulação dos dados têm a mesma sintaxe para esse fim.
Edgar Frank “Ted” Codd, pesquisador da IBM na época e que lançou o artigo intitulado
Relational Model of Data for Large Shared Data Banks, foi considerado o pai dos bancos
de dados relacionais.
ALMEIDA, R. Certificação Oracle. 2018. Disponível em: <www.linhadecodigo.com.br/

artigo/451/certificacao-oracle.aspx>. Acesso em: 04 jun. 2018.
GOMES, E. H. Linguagem SQL: linguagem de manipulação, consulta e controle de
dados. 2018. Disponível em: <ehgomes.com.br/disciplinas/bdd/sql.php>. Acesso
em: 04 jun. 2018.
KORTH, H. F.; SILBERSHATZ, A.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio
MARIADB. 2018. Disponível em: <http://mariadb.org/>. Acesso em: 04 jun. 2018.
MYSQL. 2018. Disponível em: <https://www.mysql.com/>. Acesso em: 04 jun. 2018.
POSTGRESQL. 2018. Disponível em: < https://www.postgresql.org/>. Acesso em: 04
jun. 2018.
MIRANDA, W. Certificações Oracle: diferença entre o desenvolvedor e o DBA. 2018.
Disponível em: <aprendaplsql.com/oracle/certificacao/certificacoes-oracle-diferenca-
-entre-o-desenvolvedor-e-o-dba/>. Acesso em: 04 jun. 2018.
em: 04 jun. 2018.
TRADUÇÃO DA
TERCEIRA EDIÇÃO
PROJETO, DESENVOLVIMENTO DE APLICAÇÕES

& ADMINISTRAÇÃO DE BANCO DE DADOS
Michael V. Mannino
M284p Mannino, Michael V.
Projeto, desenvolvimento de aplicações e administração
de banco de dados [recurso eletrônico] / Michael V.
Mannino ; tradução: Beth Honorato ... [et al.] ; revisão
técnica: Antônio Fernandes Nunes Guardado, Sidney da
Silva Viana. – 3. ed. – Dados eletrônicos. – Porto Alegre:
AMGH, 2014.
Editado também como livro impresso em 2008.

ISBN 978-85-8055-363-5
1. Banco de dados – Gerenciamento – Programas de

computador. 2. Projeto de banco de dados. 3. Software de
aplicativos – Desenvolvimento. I. Título.
CDD 005.74
CDU 004.658
Catalogação na publicação: Ana Paula M. Magnus – CRB 10/2052

Capítulo
14
Administração de Dados
e de Banco de Dados
Objetivos de Aprendizagem
Este capítulo oferece uma visão geral das responsabilidades e ferramentas dos especialistas em
banco de dados conhecidos por administradores de dados e administradores de banco de
dados. No final deste capítulo, o estudante deverá ter adquirido os seguintes conhecimentos
e habilidades:
• Comparar e contrastar as responsabilidades dos administradores de banco de dados e
administradores de dados.
• Controlar bancos de dados usando instruções SQL em prol da segurança e integridade.
• Gerenciar gatilhos e procedimentos armazenados.
• Compreender os papéis das tabelas dos dicionários de dados e o dicionário de recursos
de informação.
• Descrever o processo de planejamento de dados.
• Compreender o processo para escolher e avaliar SGBDs.
• Adquirir uma visão sobre os ambientes de processamento nos quais a tecnologia de banco
de dados é utilizada.
Visão Geral
Utilizando o conhecimento e as habilidades das partes 1 a 6, você provavelmente terá capaci-
dade para desenvolver bancos de dados e implementar aplicações que usam banco de dados.
Você obteve informações sobre modelagem conceitual de dados, projeto de banco de dados re-
lacional, formulação de consultas, desenvolvimento de aplicações com visões, procedimentos
armazenados, gatilhos e desenvolvimento de banco de dados usando requisitos representados
como visões. A Parte 7 complementa essas áreas de conhecimento e habilidade explorando
questões e habilidades concernentes ao gerenciamento de banco de dados em diferentes ambi-
entes de processamento. Este capítulo descreve as responsabilidades e as ferramentas dos es-
pecialistas em dados (administradores de dados e administradores de bancos de dados) e
fornece uma introdução aos diferentes ambientes de processamento de banco de dados.
Antes de conhecer os detalhes dos ambientes de processamento, você precisa com-
preender o contexto organizacional no qual os bancos de dados se encontram e conhecer as
ferramentas e os processos para gerenciá-los. Este capítulo primeiramente examina um con-
texto organizacional para banco de dados. Você obterá informações sobre o suporte do banco
de dados para o gerenciamento da tomada de decisão, os objetivos do gerenciamento de
481
482 Parte Sete Gerenciamento de Ambientes de Banco de Dados
recursos de informação e as responsabilidades dos administradores de dados e de banco de

dados. Após a explanação do contexto organizacional, este capítulo apresenta novos proces-
sos e ferramentas para o gerenciamento de banco de dados. Você aprenderá instruções SQL
para segurança e integridade, gerenciamento de gatilhos e procedimentos armazenados e
manipulação do dicionário de dados, bem como processos para o planejamento de dados e
seleção de SGBDs. Este capítulo é finalizado com uma introdução aos diferentes ambientes
de processamento, os quais serão apresentados mais detalhadamente nos outros capítulos da
Parte 7.
14.1 Contexto Organizacional para o Gerenciamento de Banco de Dados

Esta seção revisa os níveis de tomada de decisão gerencial e discute o suporte do banco de
dados para a tomada de decisão em todos os níveis. Após essa ambientação, esta seção des-
creve a função do gerenciamento de recursos de informação e as responsabilidades dos espe-
cialistas em dados no gerenciamento desses recursos.
14.1.1 Utilização do Banco de Dados como Suporte para a Tomada

banco de dados
operacional de Decisão Gerencial
um banco de dados para Os bancos de dados fornecem suporte às operações de negócio e à tomada de decisão geren-
dar suporte às funções diárias cial em vários níveis. As grandes organizações, em sua maioria, desenvolveram vários ban-
de uma organização. cos de dados operacionais para ajudar a conduzir seus negócios com eficácia. Os bancos de
dados operacionais oferecem assistência direta às principais funções organizacionais, como
processamento de pedidos, manufatura, contas a pagar e distribuição de produtos. Os fatores
que justificam o investimento em um banco de dados operacional em geral são: maior ve-
locidade de processamento, maior volume de negócios e menores custos com pessoal.
À medida que as organizações conseguem aprimorar suas operações, elas começam a
perceber o potencial para tomada de decisão de seus bancos de dados. Os bancos de dados
operacionais oferecem a matéria-prima para a tomada de decisão gerencial, como descrito na
Figura 14.1. Os níveis inferiores de gerência podem obter relatórios sobre exceções e proble-
mas diretamente dos bancos de dados operacionais. Entretanto, maior valor deve ser adi-
cionado para alavancar os bancos de dados operacionais para a alta e média gerência. Os ban-
cos de dados operacionais devem ser limpos e organizados, integrados e resumidos para
proporcionar valor para a tomada de decisão tática e estratégica. A integração é necessária
porque os bancos de dados operacionais em geral são desenvolvidos isoladamente, sem levar
em consideração as necessidades de informação da tomada de decisão tática e estratégica.
FIGURA 14.1 Apoio do Banco de Dados para os Níveis de Gerência
Hierarquia gerencial Fontes de dados externos e dados resumidos,

bancos de dados táticos
Alta
(estratégia) Bancos de dados operacionais
resumidos e integrados
Média
(tática) Bancos de dados
operacionais individuais
Baixa
(operacional)
Bancos de dados operacionais

Capítulo 14 Administração de Dados e de Banco de Dados 483
A Tabela 14.1 fornece exemplos de gerenciamento de decisões e requisitos de dados. A

baixa gerência lida com problemas de curto prazo relacionados com transações individuais.
Os resumos periódicos dos bancos de dados operacionais e os relatórios de exceção ajudam o
gerenciamento operacional. A média gerência, que se vale dos dados resumidos que são inte-
grados nos bancos de dados operacionais, pode querer integrar os dados dos diferentes de-
partamentos, fábricas e lojas de varejo. A alta gerência, que se vale dos resultados da análise
da média gerência e das fontes externas de informação, necessita integrar os dados de modo
que os clientes, os produtos, os fornecedores e outras entidades importantes possam ser lo-
calizados em toda a organização. Além disso, os dados externos devem ser resumidos e inte-
grados com os dados internos.
14.1.2 Gerenciamento de Recursos de Informação para o

Gerenciamento do Conhecimento
Em resposta aos desafios de alavancar bancos de dados operacionais e tecnologia da infor-
ciclo de vida mação para a tomada de decisão gerencial, ganhou corpo a filosofia do gerenciamento de re-
da informação cursos de informação. O gerenciamento de recursos de informação abrange o processamento,
os estágios da transformação a distribuição e a integração de informações em toda a organização. Um dos elementos prin-
da informação em uma cipais do gerenciamento de recursos de informação é o controle dos ciclos de vida da infor-
organização. O ciclo de vida mação (Figura 14.2). Cada nível de tomada de decisão gerencial e de operações de negócio
da informação é exclusivo para tem seu próprio ciclo de vida da informação. Para que a tomada de decisão seja eficaz, os ci-
cada entidade e deve ser
gerenciado e integrado com
clos de vida devem ser integrados para fornecer informações oportuna e consistentemente.
os ciclos de vida em outras Por exemplo, os ciclos de vida da informação das operações oferecem informações aos ciclos
entidades. de vida da tomada de decisão gerencial.
TABELA 14.1
Nível Gerencial Exemplos de Decisão Requisitos de Dados
Exemplos de Tomada
de Decisão Gerencial Alto Identificar novos mercados e produtos; Previsões econômicas e tecnológicas;
planejar o crescimento; realocar resumo de notícias; relatórios industriais;
recursos nas divisões. relatórios de desempenho de médio prazo.
Médio Selecionar fornecedores; fazer a previsão Tendências históricas; desempenho do
de vendas, de estoque e de caixa; examinar fornecedor; análise do caminho crítico;
os níveis de pessoal; preparar orçamentos. planos de curto e médio prazo.
Baixo Montar escala de funcionários; corrigir Relatórios sobre problemas; relatórios de

atrasos nos pedidos; identificar gargalos na exceções; escala de funcionários; resultados
produção; monitorar o uso de recursos. da produção diária; níveis de estoque.
FIGURA 14.2
Estágios Típicos do Ciclo
de Vida da Informação
Uso
Aquisição
Disseminação
Armazenamento
Formatação
Proteção
Processamento
FIGURA 14.3
Três Pilares do
Gerenciamento do Tecnologia
Conhecimento
Processamento de Dinâmica da
informações humanas organização
A qualidade dos dados é um fator especial do gerenciamento de recursos de informação

em virtude de seu impacto sobre a tomada de decisão gerencial. Como discutido no Capítulo
2, a qualidade dos dados está relacionada a inúmeras dimensões, como correção, oportu-
nidade, consistência, completude e confiabilidade. Normalmente, o nível de qualidade dos
dados suficiente para as operações de negócio pode ser insuficiente para a tomada de decisão
nos níveis de gerência superiores. Esse conflito é especialmente verdadeiro para a dimensão
consistência. Por exemplo, a inconsistência na identificação de um cliente nos bancos de
dados operacionais pode prejudicar a tomada de decisão no nível de gerência superior. O
gerenciamento de recursos de informação enfatiza um ponto de vista sobre qualidade de
dados de longo prazo para a organização como um todo com vistas a apoiar a tomada de deci-
são gerencial.
Nos últimos anos, tem havido um movimento para estender o gerenciamento de recursos
gerenciamento de informação para o gerenciamento do conhecimento. Tradicionalmente, o gerenciamento
do conhecimento de recursos de informação tem enfatizado a tecnologia no sentido de apoiar receitas pre-
aplicar a tecnologia da definidas para a tomada de decisão, em vez de a capacidade para reagir a um ambiente de
informação com as capacidades negócios em constante mudança. Para ter êxito no atual ambiente de negócios, as organiza-
humanas de processamento de
ções devem enfatizar a reação e adaptação rápidas, em vez de planejamento. Para enfrentar
informações e os processos da
organização para suportar uma esse desafio, o Dr. Yogesh Malhotra, famoso consultor gerencial, defende que as organizações
rápida adaptação à mudança. devem desenvolver sistemas que facilitem a criação de conhecimento, em vez de o gerencia-
mento da informação. Para a criação de conhecimento, ele é defensor de uma maior ênfase
sobre o processamento de informações humanas e a dinâmica da organização para equilibrar
a ênfase sobre a tecnologia, como mostrado na Figura 14.3.
Essa visão do gerenciamento do conhecimento oferece um contexto para o uso da tecnolo-
gia da informação para solucionar problemas corporativos. Não basta ter a melhor tecnologia da
informação, é preciso alinhá-la com os elementos humanos e da organização. A tecnologia da in-
formação deve ampliar a capacidade intelectual do indivíduo, compensar as limitações do
processamento humano e apoiar a dinâmica organizacional positiva.
14.1.3 Responsabilidades dos Administradores de Dados e dos

Administradores de Banco de Dados
Novas responsabilidades gerenciais surgiram como parte do controle de recursos de infor-
mação. Administrador de dados (DA, data administrator) é uma posição da média ou alta
gerência que tem amplas responsabilidades pelo gerenciamento de recursos de informação. O
administrador de banco de dados (DBA, database administrador) desempenha uma função de
suporte cujas responsabilidades estão relacionadas aos bancos de dados individuais e aos
SGBDs. A Tabela 14.2 compara as responsabilidades de ambas as funções. O administrador
de dados vê os recursos de informação em um contexto mais amplo que o administrador de
banco de dados. O primeiro considera todos os tipos de dados, estejam eles armazenados
em bancos de dados relacionais, arquivos, páginas Web ou fontes externas. O segundo nor-
malmente considera apenas os dados armazenados nos bancos de dados.
TABELA 14.2
Posição Responsabilidades
Responsabilidades dos
Administradores de Dados Administrador de dados Desenvolve um modelo de dados corporativo.
e dos Administradores de Estabelece padrões e políticas entre bancos de dados com
Bancos de Dados relação à nomeação, ao compartilhamento de dados e à
propriedade dos dados.
Negocia prazos contratuais com os fornecedores de tecnologia
da informação.
Desenvolve planos de longo prazo de tecnologia da informação.
Administrador de banco de dados Desenvolve conhecimento detalhado dos SGBDs individuais.
Procura informações sobre o desenvolvimento de aplicações.
Realiza a modelagem de dados e o projeto lógico de banco
de dados.
Faz cumprir os padrões de administração de dados.
Monitora o desempenho do banco de dados.
Realiza a avaliação técnica dos SGBDs.
Cria instruções de segurança, integridade e processamento
de regras.
Concebe padrões e políticas relacionadas aos bancos de dados
e SGBDs individuais.
modelo de dados O desenvolvimento de um modelo de dados corporativo é uma das responsabilidades

corporativo mais importantes do administrador de dados. Ele oferece um modelo integrado de todos os
um modelo conceitual de dados bancos de dados da organização. Por causa de seu escopo, ele é menos detalhado que os ban-
de uma organização. Um cos de dados individuais que ele engloba. Esse modelo concentra-se nos principais assuntos
modelo de dados corporativo
pode ser usado para o
dos bancos de dados operacionais, e não no detalhamento completo, e pode ser desenvolvido
planejamento de dados e o para o planejamento de dados (que banco de dados desenvolver) ou como suporte à tomada
suporte à tomada de decisão. de decisão (como integrar e resumir os bancos de dados existentes). A Seção 14.3 descreve
em detalhes o planejamento de dados, ao passo que o Capítulo 16 descreve em detalhes o
desenvolvimento de um modelo de dados corporativo como suporte à tomada de decisão. O ad-
ministrador de dados em geral participa significativamente de ambos esses empreendimentos.
As grandes organizações podem oferecer especialização em administração de dados e de
banco de dados. No primeiro caso, a especialização pode ocorrer por tarefa e ambiente. Em
relação à tarefa, os administradores de dados podem especializar-se em planejamento em
contraste com o estabelecimento de políticas. Em relação ao ambiente, eles podem espe-
cializar-se em ambientes como apoio a decisões e processamento de transações e em dados
não tradicionais como imagens, textos e vídeo. No caso do administrador de banco de dados, a
especialização pode ocorrer por SGBD, tarefa e ambiente. Por causa da complexidade da
aprendizagem de SGDBs, os administradores de banco de dados normalmente se especia-
lizam em um ou em poucos produtos. No que diz respeito à tarefa, a especialização em geral
se divide entre modelagem de dados e avaliação de desempenho. Com respeito ao ambiente,
a especialização em geral se divide entre processamento de transações e datawarehouses.
Nas pequenas organizações, a fronteira entre a administração de dados e a administração
de banco de dados é flexível. É provável que não haja posições distintas para administradores de
dados e de banco de dados. A mesma pessoa pode desempenhar ambas as funções. À medida
que as organizações evoluem, a especialização normalmente se desenvolve de modo que se
criem funções distintas.
14.2 Ferramentas de Administração de Banco de Dados

Para cumprir as responsabilidades mencionadas na seção anterior, os administradores de banco
de dados usam uma variedade de ferramentas. Você já obteve informações sobre ferramentas
para modelagem de dados, projeto lógico de banco de dados, projeto físico de banco de dados,
gatilhos e procedimentos armazenados. Algumas das ferramentas são instruções SQL (CREA-
TE VIEW e CREATE INDEX), ao passo que outras fazem parte das ferramentas CASE para o
desenvolvimento de banco de dados. Esta seção apresenta outras ferramentas para segurança,
integridade e acesso a dicionários de dados, e examina o gerenciamento de gatilhos e procedi-
mentos armazenados.
14.2.1 Segurança
A segurança está relacionada à proteção de um banco de dados contra acesso não autorizado
e ações mal-intencionadas de devastação. Por causa do valor dos dados nos bancos de dados
corporativos, há grande motivação por parte dos usuários não autorizados a ganhar acesso
não autorizado a esses bancos. Os concorrentes se sentem muito motivados a acessar infor-
mações confidenciais sobre planos de desenvolvimento de produtos, iniciativas de economia
de custos e perfil de clientes. O desejo dos criminosos à espreita é furtar informações ainda
não divulgadas sobre resultados financeiros e transações de negócio e dados confidenciais
sobre clientes, como número de cartão de crédito. Os transgressores sociais e terroristas
podem causar problemas e prejuízos significativos destruindo intencionalmente os registros
de um banco de dados. Dado o uso crescente da Internet para a condução de negócios, con-
correntes, criminosos e transgressores sociais têm cada vez mais oportunidade de compro-
meter a segurança dos bancos de dados.
segurança do banco Segurança é um tema amplo que envolve várias áreas. Existem os aspectos éticos e
de dados legais sobre quem pode acessar os dados e quando os dados podem ser divulgados. Existem
proteger bancos de dados contra redes, hardware, sistemas operacionais e controles físicos que aumentam os controles ofere-
acessos não autorizados e cidos pelos SGBDs. Existem ainda problemas operacionais relacionados com senhas, dis-
destruição mal-intencionada. positivos de autenticação e cumprimento da privacidade. Essas questões não são tratadas em
maior profundidade porque estão além do escopo dos especialistas em SGBDs e bancos de
dados. O restante desta subseção enfatiza as abordagens de controle de acesso e as instruções
regras de autorização
definem usuários autorizados,
SQL para regras de autorização.
operações permissíveis e partes Para o controle de acesso, os SGBDs ajudam a criação e a armazenagem de regras de au-
acessíveis do banco de dados. torização e o cumprimento dessas regras quando os usuários tentam acessar o banco de
O sistema de segurança do dados. A Figura 14.4 mostra a interação desses elementos. Os administradores de banco
banco de dados armazena regras de dados criam regras de autorização que definem quem pode acessar que parte de um banco de
de autorização e as aplica para dados e para qual operação. O cumprimento das regras de autorização requer a autenticação do
cada acesso ao banco de dados. usuário e assegura que as referidas regras não foram violadas pelas solicitações de acesso (re-
cuperação e modificação de informações do banco de dados). A autenticação ocorre quando um
usuário se conecta pela primeira vez ao SGBD. As regras de autorização devem ser verificadas
controle de acesso
discricionário
para cada solicitação de acesso.
os usuários recebem direitos ou A abordagem mais comum de regras de autorização é conhecida por controle de acesso
privilégios de acesso a partes discricionário. Nesse tipo de controle, os usuários recebem direitos ou privilégios de acesso a
específicas de um banco de partes específicas de um banco de dados. Para exercer um controle preciso, os privilégios em
dados. O controle de acesso geral são especificados para visões, e não para tabelas ou campos. Os usuários podem receber
discricionário é o tipo mais permissão para ler, atualizar, inserir e excluir partes específicas de um banco de dados. Para
comum de controle de
simplificar a manutenção das regras de autorização, é possível conceder privilégios a grupos ou
segurança suportado por
SGBDs comerciais. papéis, em vez de a usuários individuais. Pelo fato de os papéis serem mais estáveis que usuários
FIGURA 14.4
Sistema de Segurança
de um Banco de Dados
Regras de autorização
DBA
Autenticação, Sistema de segurança
requisições de acesso do banco de dados
Usuários
Dicionário de dados
individuais, as regras de autorização que fazem referência a papéis exigem menor manutenção
que as regras que fazem referência a usuários individuais. Os usuários são designados a papéis e
recebem senhas. Durante o processo de login em um banco de dados, o sistema de segurança do
controle de acesso banco de dados autentica os usuários e menciona os papéis aos quais eles pertencem.
obrigatório Os controles de acesso obrigatório são menos flexíveis que os controles de acesso dis-
uma abordagem de segurança de cricionários. Nas abordagens de controle obrigatório, a cada objeto é atribuído um nível de
banco de dados para bancos classificação e a cada usuário é atribuído um nível de autorização. Um usuário pode acessar
de dados altamente sensíveis e um objeto se o seu nível de autorização oferecer acesso ao nível de classificação do objeto em
estáticos. Um usuário pode questão. Os níveis comuns de autorização e classificação são confidencial, secreto e ultra-se-
acessar um elemento do banco creto. As abordagens de controle de acesso obrigatório foram originalmente aplicadas em
de dados se o nível de
autorização do usuário permite o
bancos de dados altamente sensíveis e estáticos para defesa nacional e coleta de informações
acesso ao nível de classificação secretas. Em virtude da limitada flexibilidade dos controles de acesso obrigatórios, apenas
do elemento. alguns SGBDs os aceitam. Entretanto, os SGBDs que são usados na defesa nacional e coleta
de informações secretas devem aceitar controles obrigatórios.
Além dos controles de acesso, os SGBDs aceitam encriptação de dados. A encriptação
envolve a codificação de dados para obscurecer seu significado. Um algoritmo de encriptação
modifica os dados originais (conhecidos por texto puro ou plaintext). Para decifrar os dados,
o usuário fornece uma chave de encriptação para restaurar os dados encriptados (conhecidos
por texto cifrado ou ciphertext) para o seu formato original (texto puro). Dois entre os algo-
ritmos de encriptação mais comuns são o padrão de encriptação de dados e encriptação de
chave pública. Pelo fato de o padrão de encriptação de dados poder ser quebrado por um
poder computacional gigantesco, o algoritmo de encriptação de chave pública tornou-se a
abordagem preferida.
Instruções de Segurança do SQL:2003

O SQL:2003 oferece suporte a regras de autorização discricionária usando as instruções
CREATE/DROP ROLE e as instruções GRANT/REVOKE. Quando se cria o papel, o SGBD
concede o papel tanto ao usuário atual quanto ao papel atual. No Exemplo 14.1, os papéis Pro-
fessorSI e ConsultorSI são concedidos ao usuário atual, enquanto o papel AdministradorSI é
concedido ao papel do usuário atual. A cláusula WITH ADMIN significa que um usuário ao
qual foi atribuído o papel pode atribuir o papel a outros usuários. A opção WITH ADMIN
deve ser usada moderadamente porque oferece ampla liberdade de ação ao papel. Um papel pode
ser suspenso com a instrução DROP ROLE.
EXEMPLO 14.1 Exemplos da Instrução CREATE ROLE

(SQL:2003) CREATE ROLE ProfessorSI;
CREATE ROLE AdministradorSI WITH ADMIN CURRENT_ROLE;
CREATE ROLE ConsultorSI;
Na instrução GRANT, você especifica os privilégios (consulte a Tabela 14.3), o objeto

(tabela, coluna ou visão) e a lista de usuários autorizados (ou papéis). No Exemplo 14.2, o
acesso SELECT é atribuído a três papéis (ProfessorSI, ConsultorSI, AdministradorSI), ao
passo que o acesso UPDATE é dado apenas a AdministradorSI. Aos usuários individuais
devem ser atribuídos papéis para que possam acessar a visão MediaGeralAlunoSI.
TABELA 14.3
Privilégio Explicação
Explicação sobre os
Privilégios Comuns do SELECT Consulta o objeto; pode ser especificado para colunas individuais
SQL:2003 UPDATE Modifica o valor; pode ser especificado para colunas individuais
INSERT Adiciona uma nova linha; pode ser especificado para colunas individuais
DELETE Exclui uma linha; não pode ser especificado para colunas individuais
TRIGGER Cria um gatilho em uma tabela estipulada
REFERENCES Menciona as colunas de uma determinada tabela nas restrições de integridade
EXECUTE Executa o procedimento armazenado
EXEMPLO 14.2 Definição de Visão e Instruções GRANT e REVOKE

(SQL:2003) CREATE VIEW MediaGeralAlunoSI AS
SELECT CPFAluno, NomeAluno, SobrenomeAluno, MediaAluno
FROM Aluno
WHERE Especializacao = ‘SI’:
-- Concede privilégios aos papéis
GRANT SELECT ON MediaGeralAlunoSI
TO ProfessorSI, ConsultorSI, AdministradorSI
GRANT UPDATE ON MediaGeralAlunoSI.MediaAluno TO AdministradorSI;
-- Designa usuários aos papéis
GRANT ProfessorSI TO Mannino;
GRANT ConsultorSI TO Olson;
GRANT AdministradorSI TO Smith WITH GRANT OPTION;
REVOKE SELECT ON MediaGeralAlunoSI FROM ProfessorSI RESTRICT;
A instrução GRANT pode também ser usada para designar usuários aos papéis, como
mostrado nas três últimas instruções GRANT no Exemplo 14.2. Além de conceder os privi-
légios da Tabela 14.3, um usuário pode ser autorizado a passar privilégios a outros usuários
por meio da palavra-chave WITH GRANT OPTION. Na última instrução GRANT do Exem-
plo 14.2, o usuário Smith pode conferir o papel AdministradorSI a outros usuários. A opção
WITH GRANT deve ser usada com moderação porque oferece ampla liberdade de ação ao
usuário.
Para remover um privilégio de acesso, é usada a instrução REVOKE. Na última ins-
trução do Exemplo 14.2, o privilégio SELECT é removido de ProfessorSI. A cláusula RES-
TRICT significa que o privilégio é revogado apenas se ele não tiver sido concedido por mais
de um usuário ao papel especificado.
Segurança no Oracle e no Access

O Oracle 10g estende as instruções de segurança do SQL:2003 com a instrução CREATE
USER, papéis predefinidos e privilégios adicionais. No SQL:2003, a criação de usuário é
tratada como implementação. Visto que o Oracle não depende do sistema operacional para a
criação de usuário, ele oferece a instrução CREATE USER. O Oracle fornece papéis pre-
definidos para usuários altamente privilegiados, incluindo o papel CONNECT, para a criação
de tabelas em um esquema, o papel RESOURCE, para a criação de tabelas e objetos de apli-
cação – por exemplo, procedimentos armazenados –, e o papel DBA, para o gerenciamento
do banco de dados. Em relação aos privilégios, o Oracle faz distinção entre privilégios de sis-
tema (independentes do objeto) e privilégios de objeto. A concessão de privilégios de sistema
normalmente está reservada aos papéis altamente seguros em virtude das amplas conseqüên-
cias que os privilégios de sistema podem causar, como mostrado na Tabela 14.4. Os privilé-
gios de objeto do Oracle são semelhantes aos do SQL:2003, exceto que o Oracle fornece mais
objetos que o SQL:2003, como mostrado na Tabela 14.5.
Os SGBDs, em sua maioria, permitem restrições de autorização por objetos de apli-
cação, como formulários e relatórios, além dos objetos de banco de dados permissíveis na
instrução GRANT. Essas outras restrições de segurança geralmente são especificadas em in-
terfaces proprietárias ou em ferramentas de desenvolvimento de aplicações, em vez de no
SQL. Por exemplo, o Microsoft Access 2003 permite que se definam regras de autorização
por meio da janela Permissões para Usuário e Grupo, como exibido na Figura 14.5. As per-
missões para os objetos de banco de dados (tabelas e consultas armazenadas), bem como para
os objetos de aplicação (formulários e relatórios), podem ser especificadas por meio dessa
janela. Além disso, o SQL aceita as instruções GRANT/REVOKE semelhantes às instruções
do SQL:2003, assim como as instruções CREATE/DROP para usuários e grupos.
TABELA 14.4
Privilégio de Sistema Explanação
Explicação sobre os
Privilégios de Sistema CREATE X, CREATE ANY X Cria objetos do tipo X no esquema de alguém; CREATE ANY
Comuns do Oracle permite que se criem objetos em outros esquemas1
ALTER X, ALTER ANY X Altera objetos do tipo X no esquema de alguém; ALTER ANY X
permite que se alterem objetos em outros esquemas.
INSERT ANY, DELETE ANY, Insere, exclui, atualiza e seleciona em uma tabela de qualquer
UPDATE ANY, SELECT ANY esquema
DROP X, DROP ANY X Exclui objetos do tipo X no esquema de alguém. DROP ANY
permite que se excluam objetos em outros esquemas
ALTER SYSTEM, ALTER Emite comandos ALTER SYSTEM, comandos ALTER DATABASE
DATABASE, ALTER SESSION e comandos ALTER SESSION
ANALYZE ANY Analisa qualquer tabela, índice ou grupo
TABELA 14.5
Procedimento, Função,
Mapeamento entre Privilégio/ Pacote, Biblioteca, Visão
Privilégios e Objetos Objeto Tabela Visão Seqüência2 Operador, Tipo de Índice Materializada3
Comuns do Oracle
ALTER X X
DELETE X X X
EXECUTE X
INDEX X
INSERT X X X
REFERENCES X X
SELECT X X X X
UPDATE X X X
FIGURA 14.5
Janela Permissões para
Usuário e Grupo no
Microsoft Access 2003
1
Esquema é um conjunto de tabelas relacionadas e outros objetos Oracle que são tratados como uma
unidade.
2
Seqüência é um conjunto de valores mantido pelo Oracle. As seqüências normalmente são usadas para
chaves primárias geradas pelo sistema.
3
A visão materializada é armazenada, em vez de derivada. As visões materializadas são úteis em
datawarehouses, como descrito no Capítulo 16.
MODELAGEM E
DESENVOLVIMENTO
DE BANCO DE DADOS
Fabrício Felipe
Meleto Barboza
Revisão técnica:
Izabelly Soares de Morais

Graduada em Licenciatura em Ciência da Computação
Mestre em Ciência da Computação
B238m Barboza, Fabrício Felipe Meleto.

Modelagem e desenvolvimento de banco de dados
[recurso eletrônico] / Fabrício Felipe Meleto Barboza, Pedro
Henrique Chagas Freitas ; [revisão técnica: Izabelly Soares de
Morais] – Porto Alegre: SAGAH, 2018.
ISBN 978-85-9502-517-2
1. Ciência da computação. 2. Banco de dados. I. Freitas,

Pedro Henrique Chagas.
CDU 004.65
Catalogação na publicação: Karin Lorien Menoncin – CRB 10/2147

Sistemas de gerenciamento
de banco de dados
Identificar os sistemas de gerenciamento de banco de dados (SGBD).

Criar dicionário de dados.
Diferenciar os sistemas de gerenciamento de banco de dados.
Introdução
Neste capítulo, você vai aprender a identificar e reconhecer os diversos
tipos de sistemas de gerenciamento de bancos de dados. Assim, será
capaz de discernir os padrões de cada um deles. Além disso, você verá
para que serve um dicionário de dados e como criá-lo. Por fim, você vai
saber diferenciar os sistemas de gerenciamento de banco de dados de
forma natural e rápida.
Os sistemas de gerenciamento de banco

de dados (SGBDs)
Para realizar o acesso a um banco de dados, é imprescindível utilizar um sistema
de gerenciamento de banco de dados (SGBD). Aí surge a grande dúvida de
qual é a diferença entre um banco de dados e um SGBD. Para facilitar o seu
entendimento, vamos relembrar o conceito de bancos de dados, mencionado
por Korth, Silberschatz e Sudarshan (2012), que definem que banco de dados
é uma coleção de dados inter-relacionados, representando informações sobre
um domínio específico. O SGDB, por sua vez, é definido por Macêdo (2012,
documento on-line) como “[...] uma coleção de programas que permitem ao
usuário definir, construir e manipular bases de dados para as mais diversas
finalidades”.
48 Sistemas de gerenciamento de banco de dados
De forma mais simples e para resumir esses conceitos, você deve considerar
que bancos de dados são a porção que representa os dados efetivamente salvos,
e o SGBD é a ferramenta que fica encarregada de salvar, editar, deletar ou ainda
garantir que esses dados estejam disponíveis quando a aplicação ou o usuário
requisitar.
Para visualizar essa discussão, veja, a seguir, a Figura 1, que mostra um
fluxo de trabalho baseado em um relatório solicitado pelo usuário em um
sistema qualquer e as etapas necessárias para que o resultado seja exibido na
tela do sistema:
Figura 1. Fluxo de trabalho.

Sistemas de gerenciamento de banco de dados 49
Ao observar a Figura 1, vemos que o fluxo de trabalho é dividido entre

alguns degraus até chegar à informação: sistema, SGBD e o dado necessário
dentro do banco de dados. Entenda que o sistema não irá acessar diretamente
o valor desejado, e sim pedir que SGBD o faça.
Novamente surge outra grande dúvida: “mas por que colocar mais com-
plexidade ao pedir que o SGBD execute a busca e retorne com os valores
desejados e não o sistema final?”.
Antigamente, quando não existiam os SGBDs, a própria aplicação final (ou
sistema final) deveria fazer essa busca e esse tratamento. O problema disso
é o aumento da complexidade do código por parte do desenvolvedor, além
do fato de que a manipulação de dados é algo muito específico. O resultado
eram sistemas com erros diversos e genéricos, com grande carga de trabalho
para a correção; quando chegavam a ela, percebiam que era uma exceção que
o banco de dados havia retornado e que não havia sido tratada.
Com o surgimento dos SGBDs, esses problemas acabaram. A aplicação
final deve se preocupar em chamar o SGBD conforme sua necessidade, passar
os valores de busca ou edição desejados e aguardar o retorno.
Esses SGBDs foram e são desenvolvidos com o único propósito de gerenciar
e manipular os dados e as variáveis dos bancos de dados, maximizando o
foco dos desenvolvedores de aplicações naquilo que elas se propõem a fazer
e entregar valor, em vez de manipular dados.
Um exemplo dessa complexidade maior ao não utilizar um SGBD é a con-
corrência. Imagine que um usuário solicita a edição de um cadastro e salva os
novos valores no mesmo segundo que outro usuário também salva a informa-
ção desse mesmo cadastro. Como deve proceder a validação? Quem deve ter
prioridade de tarefa? Qual será a forma de resolver esse impasse? Tudo isso
deveria estar dentro do código da aplicação final, caso não utilize um SGBD.
Para garantir que um SGBD esteja devidamente cumprindo seu papel,
Macêdo (2012) menciona que é importante que ele atenda a algumas caracte-
rísticas básicas de trabalho. Estas características elementares são:
controle de redundâncias;
compartilhamento de dados;
controle de acesso;
interfaceamento;
esquematização;
controle de integridade;
backups.
A seguir, você verá o conceito que cada uma dessas características engloba
e exemplos para melhor absorção do conteúdo.
Controle de redundâncias
Os valores de um banco de dados estão armazenados única e exclusivamente
em um local, evitando problemas com inconsistência devido a valores dife-
rentes. Caso o SGBD tenha replicação de dados, ela ocorrerá após o banco
de dados máster (principal) ter salvo totalmente os dados, garantindo a
integridade.
Imagine que uma planilha é enviada por e-mail para várias pessoas e cada uma delas
faz a edição conforme sua necessidade. Não será mais possível saber quais são os
valores corretos de cada campo, pois não existe um ponto único de guarda.
Compartilhamento de dados
O SGBD deve garantir que a concorrência por um mesmo valor de dados
ocorra sem problemas.
Vários acessos a um mesmo valor e ao mesmo tempo devem retornar igualmente

para todos, sem problema de valores travados ou ocupados.
Controle de acesso
Deve ser assegurado o controle de acesso ao banco de dados pelo SGBD.
Para controlar este tipo de atividade, o SGBD utiliza a relação de usuários e
permissões.
Usuário administrador que possui todos os privilégios, usuário somente para leitura,
usuário somente para escrita e leitura, etc.
Interfaceamento
Como o SGBD é o único responsável pelo acesso aos dados efetivamente
guardados, deverá disponibilizar interface de acesso aos dados presentes no
banco de dados, não podendo ser uma “caixa-preta” de informações.
Consulta por meio de linguagem SQL, interface gráfica, etc.
Esquematização
A existência de uma forma de relacionamento dos dados, presentes nas mais
diversas tabelas, deve ser clara e precisa.
Chave privada ou estrangeira.
Controle de integridade
Um SGBD deve impedir a todo custo o comprometimento do banco de dados.
Uma atividade de leitura, escrita, edição, deleção ou qualquer outra manipu-
lação ou é concluída 100% dentro das regras ou é descartada totalmente. Não
existe manipulação de dados incompleta ou quase completa.
Tentativa de gravar um valor do tipo varchar em um campo do tipo numérico resultará

em erro e não processamento.
Backups
O SGBD deve ser autônomo e conseguir recuperar-se de falhas de software
e hardware sem a intervenção do pessoal técnico ou ser minimamente de-
pendente deste pessoal.
Ao estar salvando um determinado valor, o servidor do banco de dados sofre algum

problema e reinicia. Quando o SGBD iniciar novamente, ele irá descartar aquela tran-
sação, retornando ao estado imediatamente anterior àquele job.
Dicionários de dados
Agora que você já tem conhecimento sobre as articulações dos bancos de
dados e seus sistemas de gerenciamento, como podemos padronizar as infor-
mações? Isso é importante para garantir a integridade dos dados e também
sua consistência, fatores importantes e totalmente determinantes para a saúde
do banco de dados.
O dicionário de dados vem para realizar esta padronização básica e ex-
tremamente importante, pois, à medida que o banco de dados cresce e mais
desenvolvedores são escalados para trabalhar no projeto, mais fora de padrão
pode ficar o banco de dados como um todo.
De exemplo inicial, imagine que o campo celular, por definição do escopo
inicial do projeto, deverá ser do tipo varchar e comportar a máscara “(DDD)
xxxxx-xxxx”.
Bem, tomando por base essa definição de escopo inicial, foi criada a tabela
“clientes”, na qual um dos atributos é o campo “celular”, que obedece a essas
regras. Todo o sistema da aplicação foi construído e finalizado, a implantação

no cliente final realizada e, por isso, o banco de dados também foi finalizado
com sucesso e aderente às regras.
Então, surge uma necessidade de upgrade de funcionalidade exigida
pelo cliente, o qual deseja que, no cadastro de fornecedores, coloque-se um
campo de celular de contato com esses fornecedores. Como passou muito
tempo desde o início do projeto, esqueceu-se que aquela regra do campo de
celular foi elaborada e é feito este segundo campo sem a opção de DDD ou,
ainda, em vez de utilizar o separador “-” como pede a regra, foi utilizado
o separador “.”.
Veja que o banco de dados começa a ficar confuso e sem padrão, fazendo
com que a função de chamada de cadastro apresente erro ou, ainda, que
precise ser feita de forma diferente para quando chamar o cadastro de cliente
em relação a quando chamar o cadastro de fornecedor.
Vamos além? Imagine que exista mais uma tabela que contenha o campo
celular: a tabela de cadastro de colaboradores. Ela pode ter sido desenvolvida
por outro programador e, assim, recebeu outra validação de tipo e máscara.
Extrapolando esse exemplo, pense em um sistema de aplicação gigante,
como um sistema bancário. Como garantir que todos os desenvolvedores
respeitem as mesmas regras de escopo de campos durante todo o projeto?!
A resposta para essas situações é o dicionário de dados!
No dicionário de dados, também estará a relação de usuários e permissões,
a estrutura geral e a alocação de espaço.
Assim, definindo a regra do número de celular no dicionário de dados,
todas as tabelas do sistema devem respeitar o dicionário de dados, criando um
padrão fácil de ser entendido e respeitado por todos que manipulam o sistema,
incluindo, aqui, desenvolvedores diferentes.
Um dicionário de dados é, em essência, composto por tabelas que servem de consulta

para a construção de todas as outras tabelas do SGBD.
O dicionário de dados deve ter regras e valores para cada campo das
tabelas, de modo que é natural que ocorram situações de opcionalidade de
um caractere, por exemplo.
Para sanar essa situação, você verá, no Quadro 1, um exemplo de tabela

de símbolo utilizada em um dicionário de dados qualquer:
Quadro 1. Operadores no dicionário de dados
Símbolo Significado
= é composto de
() opcional
{} cavalar
[] escolha entre uma das alternativas
** comentário
@ chave
/ separa opções alternativas
Fonte: Dicionário de Dados (2017, documento on-line).
Observe, na Figura 2, um exemplo simples de um dicionário de dados para

a construção das tabelas cidade, cliente e vendas.
Figura 2. Dicionário de dados.

Fonte: IDCODEX (2014, documento on-line).
Os diferentes Sistemas de Gerenciamento

de Bancos de Dados
Cada SGBD, seja ele MySQL, MariaDB, Oracle, Microsoft SQL Server ou
PostgreSQL, garante a base de administração e manipulação de dados estudada
e, além disso, apresenta características que o tornam ímpar.
A escolha pelo melhor SGBD se dará em virtude de qual é a aplicação a
ser desenvolvida, o fluxo de acesso, o tipo de dados a serem guardados e a
necessidade de profissionais no mercado.
Caso sua aplicação seja web, com acessos moderados e tamanho de pequeno
a médio, poderá optar pelo MySQL, MariaDB ou, ainda, pelo PostgreSQL.
Se a necessidade for a de suportar uma aplicação grande, com vários acessos
simultâneos, cruzamento de dados intenso e grande granularidade de perfis,
prefira o Oracle ou o Microsoft SQL Server.
Por fim, se a necessidade de performance estiver acima de qualquer ou-
tra frente, será necessária a utilização de bancos de dados NoSQL, como o
MongoDB, por exemplo.
Sintaxes
De forma resumida, veja, no Quadro 2, as diferentes sintaxes para exibir as
databases, selecionar uma database e também exibir as suas tabelas nos mais
diversos SGBDs.
Quadro 2. Relação de sintaxes nos SGBDs
Exibir Selecionar Exibir

SGBD databases database tabelas
MySQL/ Show databases; Use nomeDataBase; Show tables;

MariaDB
Oracle Select NAME from Connect Select table_name
v$database; nomeDataBase; from user_tables;
Microsoft Select [name] Use nomeDataBase; Select * from
SQL Server from master.dbo. sys.Tables;
sysdatabases;
PostgreSQL \list \connect \dt
nomeDataBase;
Lembre-se que cada tipo de SGBD serve para um propósito. Portanto, é necessário
entender o ambiente da aplicação para, aí sim, tomar a melhor decisão de escolha
do sistema.
DICIONÁRIO DE DADOS. Wikipédia, 2017. Disponível em: <https://pt.wikipedia.org/

wiki/Dicion%C3%A1rio_de_dados>. Acesso em: 02 jul. 2018.
IDCODEX. Trabalhando com o banco de dados MYSQL (intermediário). 19 mar. 2014.
Disponível em: <http://idcodex.id3design.com.br/?p=372>. Acesso em: 02 jul. 2018.
KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio
MACÊDO, D. SGBD - Sistema de Gerenciamento de Banco de Dados. 15 jan. 2012. Disponível
em: <www.diegomacedo.com.br/sgbd-sistema-de-gerenciamento-de-banco-de-
-dados/>. Acesso em: 02 jul. 2018.
GOMES, E. H. Linguagem SQL: linguagem de manipulação, consulta e controle de
dados. 2018. Disponível em: <ehgomes.com.br/disciplinas/bdd/sql.php>. Acesso
em: 02 jul. 2018.
em: 02 jul. 2018.

9 Banco de Dados Completo

Enviado por

Direitos autorais:

Formatos disponíveis

9 Banco de Dados Completo

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

9 Banco de Dados Completo

Enviado por

Direitos autorais:

Formatos disponíveis

FUNDAMENTOS

Ramiro Córdova Júnior

 Conceituar banco de dados.

Conceito de banco de dados

de controlar o acesso de leitura/gravação, definir a geração de relatórios e

NumEmp NomeEmp Salário Dept

Figura 1. Estrutura do banco de dados.

Uma estrutura de banco de dados é definida pelo modelo de banco de dados.

Número de ID — e uma segunda tabela chamada Proprietário do paciente —

Acesse o link a seguir e leia mais sobre conceitos de banco de dados.

Tipos de banco de dados

Banco de dados relacional

Banco de dados hierárquico

em uma tabela e, dependendo do registro consultado, obtém acesso a outras

Fábrica Financeiro Comercial

Injeção Extrusão Pagar Receber Contábil Vendas Marketing

Paulo Vinícius Vilma Sílvia João Pedro Carlos

Figura 2. Hierarquia em bancos de dados.

Banco de dados em rede

032 J Silva 380

074 M Reis 400

25 Financeiro 143 092 R Silva 480

112 R Pinto 390

130 J Neves 640

Figura 3. Rede de banco de dados.

Banco de dados objeto-relacional

 Expansibilidade: é possível ampliar a capacidade do servidor de banco

Linguagens de banco de dados

Linguagem de definição de dados (DDL)

 Para criar a instância do banco de dados — CREATE

Linguagem de manipulação de dados (DML)

As instruções DML permitem que os usuários insiram, atualizem, excluam

 Para buscar registros da(s) tabela(s) — SELECT

Linguagem de controle de dados (DCL)

GEREMIA, J. Tutorial de introdução a banco de dados. 2010. Disponível em: <http://

Tradução da Terceira Edição

☛ O que é um SGBD, em particular, um SGBD relacional?

A quantidade de informações que nos são disponíveis está literalmente explodindo, e o

A área de sistemas de gerenciamento de dados é um microcosmo da Ciên-

■ Entidades como alunos, professores, cursos e turmas.

Um sistema de gerenciamento de banco de dados, ou SGBD, é um software proje-

1.1 GERENCIANDO DADOS

1. Projeto de Banco de Dados e Desenvolvimento de Aplicativo: Como um usuário

Os capítulos posteriores abrangem tópicos importantes que estão evoluindo rapida-

1.2 UMA PERSPECTIVA HISTÓRICA

No final da década de 1960, a IBM desenvolveu o SGBD Sistema de Gerenciamento

2 A Informix foi recentemente adquirida pela IBM.

relacional, e a camada de aplicativo pode ser customizada para empresas diferentes,

1.3 ARQUIVOS DE SISTEMAS VERSUS UM SGBD

■ Provavelmente, não teremos 500 GB de memória principal para armazenar todos os

■ Devemos proteger os dados de alterações inconsistentes realizadas por usuários

Um SGBD é um pacote de software projetado para executar mais facilmente as

1.4 VANTAGENS DE UM SGBD

■ Independência de Dados: Os programas aplicativos não devem, idealmente, ser

mais robustos do que os aplicativos similares independentes porque muitas tarefas

Fabrício Felipe Meleto Barboza

 Identificar a evolução dos bancos de dados.

A evolução dos bancos de dados

Conceituar banco de dados.

Expansibilidade: é possível ampliar a capacidade do servidor de banco

Para criar a instância do banco de dados — CREATE

Para buscar registros da(s) tabela(s) — SELECT

Identificar a evolução dos bancos de dados.

Identificar a importância da utilização do banco de dados no contexto

INT ou INTEGER: recebe apenas números inteiros. Exemplo: 45002.