MODELAGEM E

DESENVOLVIMENTO
DE BANCO DE
DADOS

Fabrício Felipe
Meleto Barboza
Conceitos de banco
de dados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

„„ 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
4 Conceitos de banco de dados

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.
 Conceitos de banco de dados 5

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.

6 Conceitos 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 é
 Conceitos de banco de dados 7

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.
8 Conceitos de banco de dados

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.
 Conceitos de banco de dados 9

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).
10 Conceitos de banco de dados

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.
 Conceitos de banco de dados 11

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.

Leituras recomendadas
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:
BANCO DE
DADOS

Edinilson da Silva Vida

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

„„ Reconhecer as arquiteturas e os esquemas de banco de dados.

„„ Descrever os tipos de bancos de dados e seus usuários.
„„ Comparar as características dos principais bancos de dados relacionais.

Introdução
Os bancos de dados surgiram principalmente em função da grande
necessidade de armazenar dados de forma permanente e organizada.
É importante salientar que o volume de dados que tem surgido é cada
vez maior. Graças ao advento dos sistemas de gerenciamento de banco
de dados (SGBDs), é possível extrair diversas informações que auxiliem
no processo de tomada de decisão, exatamente no formato de que
precisamos e em poucos minutos.
Além disso, a arquitetura de um banco de dados determina a escolha
da configuração adequada para a implantação de um SGBD e as regras
para a estruturação dos dados a partir da abstração do mundo real, tudo
isso de acordo com o projeto de banco de dados. A arquitetura de um
banco de dados sofre grande influência do sistema de computadores
no qual um SGBD está instalado. Logo, saber mensurar a capacidade de
processamento exigida por um SGBD irá ser determinante para a escolha
da arquitetura mais adequada em um projeto.
No geral, os SGBDs oferecem a possibilidade de armazenar e manipular
arquivos. Alguns permitem trabalhar com diferentes arquiteturas/estru-
turas, e cada arquitetura apresenta vantagens e desvantagens quando
adotada em certo contexto e com determinada aplicação.
2 Arquitetura de banco de dados

Neste capítulo, você vai estudar as diferentes arquiteturas de sistemas

de banco de dados. Você também vai conferir os diferentes modelos de
sistemas, bem como a sua evolução histórica, as suas principais funções,
os seus recursos e as suas finalidades. Por fim, você vai explorar as carac-
terísticas e diferenças entre os principais bancos de dados relacionais.

1 Classificação dos sistemas de

gerenciamento de banco de dados
Um banco de dados, segundo Elmasri e Navathe (2011), é uma coleção de
dados relacionados que representam aspectos do mundo real (minimundo ou
universo de discurso). Mudanças no mundo real devem ser refletidas nesse
ambiente.

Para Machado (2014, p. 18), minimundo é considerado uma:

[...] porção da realidade captada pelo analista, que a gestão de negócios

de uma organização tem interesse em observar, controlar e administrar.
A complexidade existente no momento de analisar um minimundo pode
levar o analista a subdividi-lo em partes menores, às quais damos o nome
de visão de processo de negócio (MACHADO, 2014, p. 18).

Os SGBDs são constituídos por um conjunto de software com diferentes

funcionalidades, que se complementam para oferecer serviços de criação e
manipulação de bancos de dados, segundo Elmasri e Navathe (2011). Um SGBD
é um sistema de software de uso geral, que facilita o processo de definição,
construção, manipulação e compartilhamento de dados, simplificando a ex-
periência do usuário. A Figura 1 mostra a composição de um SGBD.
 Arquitetura de banco de dados 3

Programas de
aplicação

Sistema gerenciador
de banco de dados

Dados

Figura 1. Componentes de um sistema geren-

ciador de banco de dados.
Fonte: Adaptada de Cardoso e Cardoso (2013).

O SGBD oferece recursos para manipulação dos dados armazenados,

os quais permitem inserção, alteração e exclusão de dados. Além disso, o
sistema disponibiliza consultas estruturadas aos dados, recurso amplamente
utilizado na criação de relatórios. Outro mecanismo importante dos SGBDs é
o compartilhamento de dados, que dá aos usuários a possibilidade de acessar
simultaneamente o banco. Ou seja, o sistema controla os acessos e protege a
integridade dos dados.
As consultas são feitas por meio de um programa de aplicação, utilizado
pelo usuário para digitar, solicitar uma consulta e exibir o seu retorno. O
programa de aplicação pode ser qualquer software que solicite consultas de
dados a um determinado banco de dados. Nesse caso, esse programa requisita
conexão ao SGBD, enviando o usuário e a senha para autenticação. Após
aberta a conexão, o programa pode solicitar a consulta aos dados. Assim, o
SGBD é responsável por executar as consultas e devolver os dados resultantes
delas ao programa de aplicação. Os SGBDs também possuem recursos que
buscam minimizar a perda de dados em caso de problemas com software e/
ou hardware. São artifícios contra falhas inesperadas, os quais tentam evitar
que os arquivos sejam corrompidos.
É possível classificar os SGBDs quanto à arquitetura de dados, quanto ao
modelo de dados que utilizam e quanto aos tipos de dados que suportam. A
seguir, vamos estudar essas classificações.
4 Arquitetura de banco de dados

Arquitetura de dados
A arquitetura de um banco de dados sofre grande influência da arquitetura
ou do sistema de computadores no qual o SGBD está instalado. Os modelos
arquiteturais mais comuns e que estão relacionados ao esquema do ambiente
no qual o banco de dados é instalado são do tipo centralizados, cliente/servidor,
paralelos e distribuídos (GARCIA-MOLINA; ULLMAN; WIDOM, 2001),
conforme mostra a Figura 2.

Figura 2. Tipos de arquiteturas dos sistemas de gerenciamento de banco de dados.

Fonte: Adaptada de Garcia-Molina, Ullman e Widom (2001).
 Arquitetura de banco de dados 5

Cada arquitetura contém um conjunto próprio de características, como

pode ser observado a seguir (GARCIA-MOLINA; ULLMAN; WIDOM, 2001).

„„ Centralizada: oferece processamento principal para todas as tarefas do

sistema, incluindo os programas e aplicativos do usuário, o SGBD e o
próprio banco de dados. O principal motivo para a utilização desse tipo
de arquitetura ocorre por razão financeira, quando não existem recursos
financeiros suficientes para a aquisição de um conjunto adequado de
computadores com boa capacidade de processamento.
„„ Cliente/servidor: também conhecida como arquitetura em camadas,
divide as responsabilidades do sistema entre as máquinas cliente e a(s)
máquina(s) servidor. Assim, basta que outros computadores possuam
uma interface para comunicação com o SGBD que está instalado no
computador servidor. Os computadores que dão acesso ao banco de
dados são chamados de clientes, o que origina o termo “cliente/ser-
vidor”. A arquitetura cliente/servidor ainda possibilita a exploração
da capacidade de processamento dos computadores clientes para a
realização de tarefas simples, o que reduz os custos de processamento
dos computadores servidores.

Em uma arquitetura de três camadas, por exemplo:

„„ o servidor de banco de dados fica responsável pelo SGBD e pelo próprio banco
de dados;
„„ o servidor de aplicação fica responsável pelas classes e códigos relacionados às
regras de negócio da aplicação e pelo acesso ao SGBD para recuperação e, se
necessário, pré-processamento dos dados, antes de entregá-los aos clientes; e
„„ as máquinas cliente ficam responsáveis pelas classes de interface e pequenos
processamentos pertinentes ao cliente.
6 Arquitetura de banco de dados

„„ Paralela: apresenta uma estrutura hierárquica, na qual um computador

fica responsável pelo gerenciamento dos recursos, que são compartilha-
dos por todos os dispositivos ligados à rede, ou seja, ligados em paralelo.
Logicamente, assemelha-se à arquitetura centralizada; entretanto, fisi-
camente, há diversos computadores ligados em paralelo, compartilhando
poder de processamento, entrada/saída, armazenamento e memória.
„„ Distribuída: os bancos de dados estão espalhados pela rede, assim como
os componentes dos programas aplicativos que fazem uso de tais dados.

Diversas outras arquiteturas foram propostas, e os avanços da tecnologia

permitem que novas possibilidades sejam vislumbradas. Além da arquitetura
do sistema computacional, outro fator que pode influenciar na definição da
estrutura arquitetural do SGBD é a estrutura organizacional. O ideal é imple-
mentar o esquema arquitetural que melhor se adeque às necessidades do cliente.

Modelo de dados
Quando falamos dos modelos de dados de um SGBD, estamos nos referindo
à estrutura utilizada para organizar os dados no banco. Esse aspecto dos
SGBDs, em específico, tem se modificado ao longo dos anos, com o surgimento
dos SGBDs com modelos não relacionais (NoSQL), que propõem estruturas
completamente diferentes para armazenamento dos dados. Existem várias
estruturas de dados que podem ser adotadas por um SGBD. A seguir, serão
apresentados alguns modelos de SGBDs existentes.

Modelo de banco de dados hierárquico

O banco de dados hierárquico é o primeiro tipo de banco de dados de que

se tem notícia. Esse modelo foi desenvolvido por causa da consolidação dos
discos endereçáveis; em função dessa característica, a organização de endereços
físicos do disco é utilizada na sua estrutura (ALVES, 2013). A Figura 3 traz
um exemplo de banco de dados hierárquico.
 Arquitetura de banco de dados 7

Figura 3. Exemplo de um banco de dados hierárquico.

Fonte: Cardoso e Cardoso (2013, p. 23).

Segundo Alves (2013), em sistemas de banco de dados hierárquicos, são

encontrados dois conceitos fundamentais: registros e relacionamentos pai-
-filho. O registro é uma coleção de valores que representam informações
sobre uma dada entidade de um relacionamento. Quando se tem registros do
mesmo tipo, denominam-se tipos de registros, similares às tabelas/relações
do sistema relacional. Os registros que antecedem outros na hierarquia têm a
denominação de pai, e os registros que os sucedem são chamados de filhos.

Modelo de banco de dados de rede

Os sistemas de banco de dados de rede são conhecidos como CODASYL, ou

sistemas DBTG, pelo fato de terem sido definidos pelo grupo de tarefa de base
de dados (data base task group) do comitê da Conference on Data Systems
Languages (Conferência sobre Linguagens de Sistemas de Dados). O DBTG
publicou, em 1971, um relatório que “[...] descrevia o modelo e a linguagem
para utilização em bases de dados, embora esse relatório não definisse a
organização dos dados propriamente ditos” (ALVES, 2013, p. 22). A Figura
4 ilustra um exemplo de banco de dados de rede.
8 Arquitetura de banco de dados

Figura 4. Exemplo de um banco de dados de rede.

Fonte: Cardoso e Cardoso (2013, p. 22).

Conforme leciona Alves (2013, p. 22):

[...] as duas estruturas fundamentais de um banco de dados de rede são os

registros (recordes) e os conjuntos (sets). Os registros contêm dados relacio-
nados e são agrupados em tipos de registros que armazenam os mesmos tipos
de informações (como ocorre no sistema hierárquico).

Modelo de banco de dados relacional

É a estrutura mais comum aos SGBDs, e os SGBDs que a adotam são também
os mais utilizados. Temos como exemplos Oracle, Microsoft SQL Server,
MariaDB, MySQL, PostgreSQL etc. O modelo de dados relacional foi criado
em 1985 por Edgar Frank Codd, que definiu que os bancos desse modelo
devem apresentar a informação uma única vez, ou seja, devem possuir um
identificador de cada informação para que não haja registros duplicados. Além
disso, os dados precisam estar dispostos em forma de tabela. Ao todo, foram
estabelecidas premissas para o modelo relacional, das quais podemos destacar:

„„ relações de integridade;
„„ recursos para inserção, alteração e remoção de dado em alto nível;
„„ acesso ao dado por meio da consulta de sua tabela.

A arquitetura das tabelas é dada pelo estabelecimento de relações e pelo uso

de tuplas e atributos. Portanto, nos bancos de dados do modelo relacional, os
dados são sempre salvos em tabelas, que nada mais são do que uma estrutura
de linhas e colunas.
 Arquitetura de banco de dados 9

Tabelas

Quando falamos que as tabelas são relações, estamos dizendo que as lógicas
entre os dados do banco são definições da tabela. Ao criar e modificar uma
tabela, podemos estipular que determinados atributos se relacionam com dados
de outra tabela. A construção dessas relações é fundamental para que quem
precisar utilizar o banco possa executar consultas posteriores e compreender
a lógica entre os dados.

Registros

Temos ainda os registros, também conhecidos como linhas ou tuplas. Todas

as linhas de tabela são referências aos atributos definidos pelas colunas. É
permitido que as linhas aceitem atributos com valores nulos, ou vazios, desde
que isso tenha sido definido na estrutura da tabela, ou seja, que esteja espe-
cificado nos metadados.

Atributos

Por último, temos as colunas ou atributos, que são as identificações dos da-
dos. Os atributos são responsáveis por caracterizar os dados inseridos em
determinada coluna.

Modelo de banco de dados orientado a objetos

Os bancos de dados orientados a objetos trabalham com o armazenamento

de dados na forma de objetos. Nesse caso, a definição de objetos é similar ao
conceito utilizado nas linguagens de programação, como Java. Esse modelo
é adotado quando os modelos de dados se tornam extremamente complexos
para manipulação por meio de relações no modelo relacional. Assim, o arma-
zenamento em objetos facilita o acesso e o uso dos dados quando o software
trabalha com alguma linguagem orientada a objetos, evitando o consumo de
tempo na conversão de tuplas em objetos, ao se utilizar um banco de dados
relacional e uma linguagem orientada a objetos. Os dados ou objetos só podem
ser acessados pelos métodos predefinidos para eles, e um objeto pode conter
referências a outros objetos.
10 Arquitetura de banco de dados

Modelo de banco de dados objeto-relacional

O modelo de dados objeto-relacional identifica os SGBDs que mesclam as

características do modelo relacional e do orientado a objetos. Em resumo,
armazena os dados conforme o modelo relacional, com tabelas estruturadas,
mas possibilita a conversão imediata das tuplas em objetos. Também oferece
a possibilidade da manipulação dos dados por meio da linguagem SQL (struc-
tured query language).

Modelo de banco de dados semiestruturado

Os bancos de dados desenvolvidos no modelo semiestruturado são pouco

utilizados se comparados com as arquiteturas anteriores. Por não possuí-
rem uma estrutura rígida, possibilitam perda da integridade dos dados. São
aqueles que não utilizam o modelo relacional integralmente, mas contam
com marcações para organização dos dados. Bancos de dados desse modelo
não possuem linguagem de consulta padrão; por isso, deve ser observada a
linguagem adequada para cada caso.

Modelos de banco de dados NoSQL (ou não relacionais)

Em 1998, surgiu o termo NoSQL, a partir de uma solução de banco de dados

ainda baseada na arquitetura do modelo relacional e que não oferecia, para
o seu usuário, uma interface SQL. Posteriormente, o termo tornou-se uma
abreviação para not only SQL (“não apenas SQL”), oferecendo uma solução
alternativa para os cenários em que o consagrado modelo relacional não apre-
sentava o desempenho adequado. O objetivo das soluções NoSQL é fornecer
uma solução com maior flexibilidade na estruturação de um banco de dados,
quando houver essa necessidade. Portanto, seu propósito não é o de substituir
o modelo relacional de dados.
Podemos categorizar os modelos de dados NoSQL pela estrutura com que
trabalham: família de colunas, documentos, chave-valor e grafos, descritos
a seguir.

„„ Família de colunas: armazena dados mapeados por chaves, e os da-

dos agrupados formam uma espécie de mapa. Exemplos: BigTable e
Cassandra.
 Arquitetura de banco de dados 11

„„ Documentos: armazena documentos como um valor, que possui uma

chave para identificação, como no modelo por chave. Exemplos: Mon-
goDB e CouchDB.
„„ Chave-valor: guarda uma informação ou valor e cria uma referência
para acessá-lo, a chave. Exemplo: Amazon Dynamo.
„„ Grafos: trata-se da criação de nodos, ou entidades, ou nós. As arestas do
grafo são as representações das relações. Exemplos: InfoGrid e Neo4j.

Assim como os bancos de dados semiestruturados, os bancos de dados

NoSQL não apresentam linguagem de consulta padrão, até pelo fato de terem
estruturas diferentes entre si.

Esquema de dados
Podemos afirmar que, em um modelo de dados, um esquema é uma descrição
em uma linguagem formal da estrutura do banco de dados. De acordo com
Alves (2013, p. 32), “[...] para construção de um esquema, devem ser despre-
zadas todas as especificações dos campos das tabelas, listando apenas os seus
nomes”. Na Figura 5, podemos observar um exemplo de um diagrama para o
esquema de um banco de dados. É possível notar a identificação das chaves
primárias de cada tabela, observando o sublinhado que foi colocado no nome
dos referidos campos.

Figura 5. Exemplo de um esquema de banco de dados.

Fonte: Alves (2013, p. 33).
12 Arquitetura de banco de dados

A arquitetura de três esquemas é também conhecida como arquitetura ANSI/

SPARC, em que ANSI se refere ao American National Standards Institute, e
SPARC se refere ao Standards Planning and Requirements Committee. Ela
tem o objetivo de separar o usuário da aplicação do banco de dados físico, por
meio de três diferentes níveis de esquemas (ELMASRI; NAVATHE, 2011),
descritos a seguir.

„„ Interno: a partir de um esquema interno, o nível interno descreve a

estrutura de armazenamento físico do banco de dados. Assim, é possível
descrever os detalhes complexos do armazenamento, bem como os
caminhos de acesso ao banco de dados.
„„ Externo: ao abranger os esquemas externos ou visões de usuários,
no nível externo, o esquema externo descreve determinada parte do
banco de dados que um dado grupo de usuários tenha interesse. Além
disso, oculta o restante do banco de dados desse grupo. Nesse nível, ao
utilizar um modelo de dados representacional, cada esquema externo
é tipicamente implementado. Isso é feito, possivelmente, com base em
um projeto de esquema externo em um modelo de dados de alto nível.
„„ Conceitual: por meio de um esquema conceitual, descreve a estrutura
de todo o banco de dados para seus usuários. Por ele, são ocultados os
detalhes das estruturas de armazenamento físico, concentrando-se na
descrição de entidades, tipos de dados, conexões, operações de usuários
e restrições. Quando o sistema de banco de dados é implementado, ge-
ralmente, um modelo de dados representacional é usado para descrever
o esquema conceitual. Dessa forma, é fundamentado em um projeto de
esquema conceitual, em um modelo de dados de alto nível.

Tipos de dados
Com o passar do tempo, surgiram novos tipos de dados, e, consequentemente,
os SGBDs se adaptaram para aceitá-los sem a necessidade de trabalhar com
conversões o tempo todo. Atualmente, quanto aos tipos de dados, os SGBDs
podem ser classificados em dados clássicos, textos/documentos, dados multimí­
dia e dados geográficos, categorias descritas a seguir.

„„ Dados clássicos: comportam apenas valores numéricos e textuais.

„„ Textos/documentos: armazenam os dados em formato de texto ou
documentos. Normalmente utilizam arquivos com a extensão XML.
 Arquitetura de banco de dados 13

„„ Dados multimídia: armazenam imagens, arquivos em PDF, entre outros.

„„ Dados geográficos: reconhecem pontos, linhas e polígonos, que são
utilizados para criar representações do espaço.

Níveis de abstração
Na arquitetura de banco de dados, temos várias categorias de modelos de
dados. Podemos classificar cada modelo de acordo com os tipos de conceitos
utilizados para descrever sua estrutura. Os modelos de dados conceituais, ou
modelos de alto nível, possuem conceitos que descrevem os dados como são
percebidos pelos usuários. Os modelos de dados conceituais usam conceitos
como entidades, atributos e relacionamentos. Uma entidade corresponde a um
objeto do mundo real descrito no banco de dados. Um atributo corresponde a
uma propriedade que auxilia na descrição de uma entidade. O relacionamento
entre duas ou mais entidades representa uma associação entre elas.
Os modelos de dados físicos, ou modelos de baixo nível, contêm conceitos
que descrevem os dados, detalhadamente, como estão armazenados no banco
de dados. Esses modelos descrevem os dados pela representação do formato
dos registros, da ordem e da disposição dos registros e das suas rotas de acesso,
que são estruturas que tornam as pesquisas por registros no banco de dados
mais rápidas e eficientes. Os conceitos obtidos dos modelos de dados de baixo
nível geralmente são mais significativos para os especialistas em tecnologia
da informação do que para os usuários finais das aplicações.
Entre esses dois níveis extremos, temos uma classe de modelos de dados
chamada de modelos representacionais ou de implementação, que descreve
conceitos que ocultam alguns detalhes de como os dados estão organizados e
armazenados no banco de dados. Estes, porém, podem ser interpretados pelos
usuários finais dos aplicativos. Atualmente, os modelos de dados representa-
cionais são os mais usados comercialmente pelos SGBDs mais tradicionais.
Essa classe inclui o modelo de dados relacional, utilizado mais popularmente
nos projetos de bancos de dados, e também os modelos hierárquicos e os
modelos de rede, considerados modelos de dados legados, que já foram muito
utilizados no passado.
14 Arquitetura de banco de dados

2 Principais sistemas de gerenciamento de

banco de dados disponíveis no mercado
Nesta seção, serão apresentados alguns exemplos e características de SGBDs
comerciais e gratuitos que estão disponíveis no mercado. Para isso, eles serão
separados em SGBDs relacionais e SGBDs não relacionais.

Sistemas de gerenciamento de banco de dados relacionais

Veja a seguir alguns dos principais SGBDs relacionais disponíveis no mercado.

Oracle

A Oracle é uma empresa que surgiu nos anos 1980. Hoje, é uma das maiores
do mercado da tecnologia da informação e é proprietária de diversos recursos
conhecidos, como o banco da Oracle e o pacote de desenvolvimento Java. O
SGBD é um dos produtos mais conhecidos da empresa e é utilizado mundial-
mente. É uma ferramenta robusta, constantemente atualizada e aperfeiçoada
para atender às demandas do mercado. Esse SGBD é desenvolvido com foco
no mercado empresarial, e seus recursos atendem a empresas de pequeno e
grande porte. Adota o modelo de dados relacional e oferece a possibilidade de
manipulação de seus dados por meio da linguagem procedural/SQL. A Oracle
trabalha com o lançamento de diferentes versões, com características diferentes
e adequadas a necessidades diversas, sob a concessão de diferentes licenças.

MySQL

O banco de dados MySQL também é um dos mais populares em todo o mundo.

É uma tecnologia de código aberto, que permite que os usuários e as organi-
zações modifiquem o SGBD de acordo com as suas necessidades. O MySQL
foi criado na Suécia, por volta da década de 1980. Em 2009, foi vendido para
a Oracle por cerca de um bilhão de dólares. É um banco de dados que pode
ser utilizado em diferentes plataformas. O seu uso é simples, o que o torna
muito conhecido.
 Arquitetura de banco de dados 15

Microsoft SQL Server

A primeira versão do SQL Server, que é o SGBD relacional da Microsoft, foi

lançada em 1988 como componente do sistema operacional Windows NT.
Somente em versões posteriores foi comercializado como um produto para
aquisição individual. A grande diferença em relação aos outros SGBDs citados
é que o SQL Server possibilita a realização de consultas e a manipulação dos
dados por meio de linguagens de programação, como a C# e a Visual Basic.
Ainda, é possível trabalhar com a linguagem SQL. O SQL Server também pode
ser integrado aos recursos do SQL Server Management Studio e à extensão
para linguagem T-SQL. Apesar de ser uma solução paga, é um dos bancos de
dados mais utilizados no mundo, devido à sua qualidade e robustez.

PostgreSQL

O PostgreSQL é um banco de dados de modelo objeto-relacional, de código

aberto, lançado em 1989. É um dos mais utilizados na atualidade, especial-
mente para o desenvolvimento de sistemas web e de soluções para demandas
de negócios. Esse SGBD é considerado, por muitos, o melhor banco de dados
de código aberto disponível; por isso, é adotado por diversas organizações
públicas, no Brasil e no exterior.

MariaDB

O MariaDB é um banco que surgiu com base no MySQL e ganhou popularidade

rapidamente. Quando a Oracle adquiriu o MySQL, decidiu trabalhar em um
novo SGBD para aprimorar as características do MySQL. Então, em 2009, foi
lançado o MariaDB. Esse SGBD possui boas perspectivas de crescimento no
mercado, principalmente devido à sua simplicidade de uso e à preocupação
com a segurança dos dados.

Sistemas de gerenciamento de banco de dados não relacionais

Veja a seguir alguns dos principais SGBDs não relacionais disponíveis no

mercado.
16 Arquitetura de banco de dados

MongoDB

É um banco de dados relativamente recente. Sua primeira versão foi lançada

em 2009, e seu uso vem se expandindo desde então. O MongoDB é um banco
de dados NoSQL, de código aberto, que trabalha com o modelo de dados
orientado a documentos. Foi desenvolvido para unir características dos bancos
de dados relacionais e NoSQL. Como resultado dessa mistura de abordagens,
o MongoDB apresenta ganhos de agilidade com o uso de esquemas flexíveis
e facilita a escalabilidade horizontal, recursos pouco explorados por outros
SGBDs, como MySQL e PostgreSQL. O uso do MongoDB tem aumentado,
o que levou a uma expansão conjunta da linguagem JavaScript, utilizada por
esse SGBD.

Redis

O Redis é um banco de dados que também trabalha com o modelo de dados

NoSQL. A estruturação de seus dados é feita com base no modelo chave-valor.
É capaz de armazenar textos, listas, conjuntos, entre outros itens. Assim como
outros dados NoSQL, o interesse das empresas em seu uso vem crescendo
significativamente.

Cassandra

O Cassandra, assim como o MongoDB, é um banco de dados NoSQL. Foi

criado pelo Facebook, que tornou o projeto de código aberto em 2008. Hoje
é mantido pelos membros da fundação Apache. Esse SGBD também adota
a linguagem JavaScript. Sua grande vantagem frente a outros SGBDs é a
capacidade de escalabilidade sem causar perdas de performance.

Os usuários do sistema de banco de dados

Para um sistema de banco de dados aplicado em um projeto de média ou alta
complexidade, existem muitos profissionais (usuários) envolvidos desde a fase
de criação do projeto até a fase de manutenção propriamente dita. De acordo
com Cardoso e Cardoso (2013, p. 24), “[...] no ambiente de um sistema de
banco de dados é importante definir os usuários e suas funções específicas,
sendo que a cada um cabe uma tarefa diferenciada”.
 Arquitetura de banco de dados 17

Para Alves (2013), os usuários podem ser classificados conforme descrito

a seguir.

„„ Projetistas de banco de dados: profissionais cuja responsabilidade

é identificar todos os dados que devem ser armazenados no banco de
dados, assim como determinar a sua estrutura por meio da especificação
de um modelo de dados. Para se chegar a essa fase, é necessário um
levantamento das necessidades dos usuários finais. O projeto final
do banco de dados deve atender a essas necessidades, sendo o mais
completo possível.
„„ Analistas de sistemas e programadores: os analistas de sistemas são
responsáveis pela especificação da estrutura e das funcionalidades
do aplicativo, depois de se determinarem as necessidades dos usuá-
rios. Então, os programadores, com base no modelo de dados definido
pelo projetista de banco de dados e nas especificações dos analistas,
desenvolvem a aplicação propriamente dita, criando formulários de
interface com o usuário e códigos que executam tarefas importantes.
São eles também os responsáveis pela documentação e manutenção
do sistema. Para o desenvolvimento, é imprescindível que analistas e
programadores estejam familiarizados com o SGBD e a linguagem de
programação adotados.
„„ Administradores de banco de dados: são os profissionais responsáveis
pela administração dos recursos oferecidos pelo SGBD, também co-
nhecidos como database administrator (DBA). Entre as suas principais
tarefas, estão: definir novos usuários do sistema, determinar níveis de
acesso a cada usuário, monitorar o uso do sistema e efetuar manuten-
ções preventivas (como cópia de segurança e restauração de bancos de
dados). O DBA é responsável por planejar, documentar e gerenciar os
recursos de informação do negócio em que atua.
„„ Usuários finais: são as pessoas que efetivamente fazem uso do aplicativo
e, por conseguinte, do banco de dados. Este foi elaborado principal-
mente para atender às exigências que esses usuários apresentaram aos
projetistas e analistas.

Podemos concluir que os usuários podem ser diferenciados ou agrupados

conforme seus papéis e suas expectativas de interação com o sistema de
banco de dados.
18 Arquitetura de banco de dados

3 Comparativo entre os principais sistemas de

gerenciamento de banco de dados
No Quadro 1, podemos ver os principais SGBDs disponíveis no mercado, de
acordo com as características que vimos até o momento.

Quadro 1. Relação dos principais SGBDs e suas características

Tipo de Arqui-
SGBD Plataforma Modelo
licença tetura

Cassandra Multiplataforma Gratuita Distribuída Família de

colunas

Firebird Multiplataforma Gratuita Cliente/ Relacional

servidor

IBM DB2 Multiplataforma Paga Cliente/ Relacional

servidor

Interbase Multiplataforma Paga Cliente/ Relacional

servidor

MariaDB Multiplataforma Gratuita Cliente/ Relacional

servidor

Microsoft Multiplataforma Paga e Cliente/ Relacional

SQL Server gratuita servidor

MongoDB Multiplataforma Gratuita Distribuída Documentos

MySQL Multiplataforma Paga e Cliente/ Relacional

gratuita servidor

Oracle Multiplataforma Paga e Cliente/ Relacional

gratuita servidor

PostgreSQL Multiplataforma Gratuita Cliente/ Objeto-

servidor relacional

Redis Multiplataforma Gratuita Distribuída Chave-valor

 Arquitetura de banco de dados 19

Como complemento, o site BD-Engines é uma ferramenta muito útil para

realizar pesquisas e comparativos entre SGBDs e, além disso, oferece uma
lista de SGBDs classificados de acordo com a sua popularidade no mercado,
seguindo uma publicação mensal. Observe, na Figura 6, a listagem classifica-
tória dos 10 primeiros SGBDs. Nessa listagem, lançada em fevereiro de 2020,
podemos identificar que os SGBDs Oracle, MySQL e Microsoft SQL Server
estão com grande vantagem de utilização em relação aos demais colocados.

Figura 6. Classificação dos sistemas de gerenciamento de banco de dados de acordo com

a sua popularidade no mercado.
Fonte: DB-Engines (c2020, documento on-line).

ALVES, W. P. Banco de dados. São Paulo: Érica, 2013.

CARDOSO, V.; CARDOSO G. Sistemas de banco de dados: uma abordagem introdutória
e aplicada. São Paulo: Saraiva, 2013.
DB-ENGINES. DB-Engines ranking. c2020. Disponível em: https://db-engines.com/en/
ranking. Acesso em: 4 abr. 2020.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São Paulo: Pearson, 2010.
GARCIA-MOLINA, H.; ULLMAN, J. D.; WIDOM, J. Implementação de sistemas de bancos
de dados. Rio de Janeiro: Campus, 2001.
MACHADO, F. N. R. Projeto e implementação de banco de dados. São Paulo: Érica, 2014.
20 Arquitetura de banco de dados

Leituras recomendadas
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2011. 4 v.
SETZER, V. W.; SILVA, F. S. C. da. Bancos de dados: aprenda o que são, melhore seu co-
nhecimento, construa os seus. São Paulo: Blucher, 2005.