Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)_Topico_2

Prévia do material em texto

07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 1/15
Arquiteturas de Sistemas Gerenciadores de
Bancos de Dados (SGBD)
Arquitetura de dados relacionais I
1. Introdução
Um sistema de gerenciamento de banco de dados (SGBD) é uma coleção de programas que
possibilita a definição, a implementação, a manipulação, o compartilhamento e a segurança dos
bancos de dados (BD). A partir dos programas de aplicação, os SGBDs permitem que os usuários
acessem e manipulem os dados armazenados em banco de dados, como mostra a Figura 01.
Entretanto, a forma como isso ocorre irá depender do tipo da demanda do programa de aplicação.
Essa demanda pode ser uma arquitetura simples, onde se tem apenas uma aplicação e um banco de
dados sendo executados em um mesmo local, ou uma arquitetura robusta e distribuída, onde se
pode ter diversos programas de aplicação e partes de um banco de dados distribuídos em uma rede
de computadores.
 
As arquiteturas dos SGBDs evoluíram de modo similar às arquiteturas dos sistemas
computacionais. Inicialmente, elas eram baseadas em computadores de grande porte (mainframes)
e processavam todas as funcionalidades do SGBD. Grande parte dos usuários acessavam o sistema
Arquitetura geral de um Sistema de Banco de Dados.
https://cead.uvv.br/conteudo/wp-content/uploads/2022/08/substituicao1-6.png
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 2/15
por meio de terminais de computador sem nenhum poder de processamento. Ao longo do tempo,
esses sistemas foram substituídos por SGBDs com design modular e arquitetura de sistema cliente/
servidor. Atualmente, o crescimento do volume de dados a serem armazenados conduziu à adesão
de sistemas com arquiteturas distribuídas, formadas por várias máquinas que gerenciam e
armazenam esses dados.
 
De acordo com Berg, Seymour e Goel (2012), a história dos Sistemas Gerenciadores de Banco de
Dados teve início na década de 60, mesma época da introdução da tecnologia de armazenamento
em disco. Nessa época, dois dos principais modelos de dados foram desenvolvidos: o modelo de
dados hierárquico, seguido do modelo de dados em rede.
Os primeiros SGBDs, conforme Patrick (2009) e Bachman (2009), nasceram nessa década, de
forma independente e em contextos diferentes. O primeiro SGBD de acesso direto foi o IDS -
Integraded Data Store (Depósito de Dados Integrados), lançado em 1964. Ele teve um traço mais
acadêmico e foi conduzido por Charles Bachman, na General Electric. Bachman também foi o
responsável pela criação do diagrama de estrutura de dados, denominado por Diagrama de
Bachman, que inspirou o trabalho Modelo Entidade-Relacionamento, do Peter Chen, na década
de 70 conforme relata Bachman (1969). O IDS foi a base do modelo de dados de rede, padronizado
no final da década de 60 pela CODASYL (Conference on Data Systems Languages). O outro SGBD
foi uma inovação nascida da necessidade de um ambiente industrial, no sul da Califórnia, o IMS
(Information Management System) da IBM, lançado pouco depois do IDS e que constituiu a base
do modelo de dados hierárquico, segundo Patrick (2013). O IMS foi muito útil para as
empresas que trabalhavam com uma abordagem mais centralizada para o gerenciamento de dados.
 
Baseado na teoria de conjuntos, o pesquisador Edgar Frank Codd, propôs o modelo de dados
relacional em 1970. Esse modelo impulsionou o desenvolvimento de vários SGBDs, mas devido ao
baixo desempenho em relação aos modelos em rede e hierárquico, na prática, ainda eram pouco
utilizados. Na década de 1980, o modelo relacional se consolidou como modelo dos SGBDs e o seu
uso se difundiu. Nessa mesma época, a IBM desenvolveu o System R e a linguagem de consulta SQL
para os bancos de dados relacionais que, no final dessa mesma década, foi padronizada pela
American National Standards Institute (ANSI) e pela International Organization for
Standardization (ISO). Os primeiros bancos de dados relacionais foram o IBM DB2, o Oracle, o
Ingres e o DEC Rdb, eles tiveram grande influência para o desenvolvimento de novas técnicas para
geração de consultas mais eficientes.
Você conhece a história dos SGBDs?
Sabe quando foi criado o primeiro SGBD?
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 3/15
No final da década de 80, com o surgimento das linguagens de programação orientadas a objetos e
a necessidade de armazenamento de dados mais complexos e estruturados, foi iniciado o
desenvolvimento dos bancos de dados orientados a objetos (BDOO), de acordo com Elmasri
e Navathe (2018). A princípio, os BDOOs foram considerados concorrentes dos BDRs, pois
agregavam os conceitos do paradigma orientado a objetos. Entretanto, a sua adesão pelo mercado
foi baixa e, atualmente, são mais utilizados em aplicações especializadas. Conforme Silberschatz,
Korth e Sudarshan (2020), nessa mesma época, iniciaram as pesquisas sobre os bancos de dados
distribuídos.
Pesquisas para o desenvolvimento de modelos e linguagens de consulta mais robustas, que
atendessem às novas demandas das empresas, de forma especial, o suporte à decisão, cresceram
consideravelmente a partir dos anos 90. Alguns fabricantes incluíram em seus produtos a
capacidade de armazenar novos tipos de dados (imagens, vídeos, etc.) e realizar consultas mais
complexas, além de adicionarem suporte objeto-relacional, dando origem aos bancos de dados
objeto-relacional (BDOR). O crescimento da World Wide Web (WWW) demandou dos SGBDs o
suporte à altas taxas de processamento de transações, bem como alta confiabilidade e
disponibilidade.
Na década de 2000, houve um crescimento no uso dos tipos de dados semiestruturados e os
bancos de dados relacionais começaram a dar suporte aos formatos XML e JSON e aos dados
espaciais. O crescimento das redes sociais levou ao desenvolvimento de bancos de dados gráficos. A
demanda por análise e mineração de grandes volumes de dados nas empresas conduziu à criação de
sistemas de bancos de dados especializados. Nessa época, também foram criadas as primeiras
versões de Sistemas Gerenciadores de Banco de Dados do tipo NoSQL (not only SQL), com
várias limitações, como falta de suporte para consistência e consultas declarativas.
A partir de 2010, os sistemas NoSQL passaram a fornecer suporte e recursos padrão de um sistema
de banco de dados. Entretanto, essa década foi marcada pelo armazenamento em “nuvem”,
onde os dados são hospedados em servidores distribuídos e entregues aos usuários por meio de
serviços baseados na web, o que possibilitou um maior número de problemas de segurança e perda
de privacidade.
Com um número de usuários e volume de dados crescentes, iniciou-se uma nova década com
aumento de demandas de gerenciamento e análise de dados cada dia mais eficientes. Além disso,
os problemas de segurança e privacidade continuam desafiadores e requerendo novas pesquisas
para garantir a integridade e a robustez dos bancos de dados.
Para aprofundar um pouco mais sobre o assunto, indicamos a seguinte leitura:
BERG, K.; SEYMOUR, J. T., RICHA, G. History of databases. International Journal of Management &
Information Systems (IJMIS). v17. n.1, 2013.
Clique aqui
https://www.researchgate.net/publication/298332910_History_Of_Databases
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 4/15
2. Características, propriedades e recursos
dos sgbdsUma característica fundamental dos SGBDs, de acordo Elmasri e Navathe, (2016) é que eles
trabalham com vários níveis de abstração de dados, ocultando detalhes de como os dados são
armazenados e mantidos, e destacando características essenciais para o seu entendimento. O que
simplifica e melhora a interação dos usuários com o sistema, permitindo que eles percebam os
dados no nível de detalhe desejado. 
Essa abstração pode ser alcançada por meio dos modelos de dados. O modelo de dados é uma
forma de representar conceitualmente a estrutura dos bancos de dados que retratam o ambiente
observado (contexto), como os objetos, suas características, relacionamentos e restrições. De
acordo Silberschatz, Korth e Sudarshan (2020), um modelo de dados é “uma coleção de
ferramentas conceituais para descrever dados, relações de dados, semântica de dados e restrições
de consistência”.
Elmasri e Navathe (2018), classificam os modelos de dados em três grupos, de acordo com o
conceito utilizado para representação da estrutura do BD, são eles: o modelo conceitual, o modelo
de implementação (lógico) e o modelo físico. O modelo conceitual representa os conceitos e as
características observadas em um dado ambiente. Assim, os objetos, suas características e
relacionamentos têm a representação fiel ao ambiente observado, ou seja, o modelo conceitual é
independente de quaisquer limitações impostas por tecnologias, técnicas de implementação ou
dispositivos físicos. O modelo físico descreve como o dado é armazenado no computador, ou em
uma rede de computadores, mostrando formatos, ordenações e caminhos para acessá-lo. De acordo
com Cougo (1997), cada SGBD pode definir diferentes formas de implementação física para o
armazenamento e a manipulação das estruturas de dados. Pode-se ter, inclusive, um mesmo SGBD
com diferentes implementações físicas quando se encontra em diferentes ambientes operacionais
(por exemplo, um SGBD rodando em Windows e Linux terão formas diferenciadas de
implementação física). Entre os modelos conceitual e físico, temos o modelo de implementação
(ou lógico). Ele representa os objetos, as características desses objetos e seus relacionamentos de
acordo com as regras de implementação e limitações impostas por algum tipo de tecnologia. 
Como exemplo, vamos pensar no seguinte cenário: uma clínica médica que requer o
armazenamento de dados a respeito das consultas realizadas pelos médicos a seus pacientes. Os
dados a serem armazenados dos médicos são o CRM, o nome e a especialidade; os dados do
paciente, o CPF, o nome, o endereço e o telefone; e, por fim, a data e a hora de cada consulta. 
Os modelos conceitual e lógico, desse contexto, estão nas Figuras 02 (a) e (b), respectivamente.
Veja que, no modelo conceitual, os retângulos simbolizam as entidades (conjunto de objetos com
mesmas características), o losango representa o relacionamento entre essas entidades e as elipses
representam as características das entidades e relacionamento. A Figura 02 (b) mostra a derivação
do modelo conceitual para o modelo lógico relacional, onde as entidades, relacionamentos e
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 5/15
atributos passam a ser representados de acordo com as restrições impostas pela tecnologia
utilizada, neste caso, a relacional. Assim, as entidades e o relacionamento entre elas tornam-se
tabelas, onde suas colunas representam cada um dos atributos das respectivas entidades e
relacionamento.
Os SGBDs fornecem uma arquitetura denominada Arquitetura de Três Esquemas, que é baseada
em três níveis de abstração: o nível interno (ou físico), o conceitual (ou lógico) e o externo (ou de
visão). O objetivo dessa arquitetura é fazer a separação entre as aplicações do usuário e o banco de
dados físico, facilitando a interação dos usuários com o sistema. 
A Figura 03 mostra a relação entre os três níveis: o nível interno (ou nível físico) é o mais baixo,
nele temos o esquema interno (ou físico) que descreve os detalhes sobre a forma de
armazenamento dos dados (estruturas de dados) e os caminhos de acesso a eles. O nível
intermediário de abstração é o conceitual (ou lógico), que tem um esquema conceitual (lógico)
que descreve o BD em um nível mais alto. Ele esconde detalhes da implementação e se concentra na
a) Modelos de dados conceitual
b) Modelo de dados de implementação (lógico relacional).
Dois conceitos importantes na abordagem de banco de dados são: esquema e instância. Esquema
é a descrição do banco de dados em algum nível de detalhe, ele é baseado no modelo de dados;
enquanto a instância é o estado em que se encontra o banco de dados em um determinado
momento.  Silberschatz, Korth e Sudarshan (2020) os compara como um programa escrito em uma
linguagem de programação, onde o esquema de BD corresponde às declarações de variáveis no
programa que, a cada instante, vai possuir um valor específico. Esses valores correspondem à
instância de um esquema no BD.
https://cead.uvv.br/conteudo/wp-content/uploads/2022/08/substituicao1-11-768x525.png
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 6/15
descrição de dados, relacionamentos e restrições. Por fim, o nível mais alto de abstração, o nível
externo, que retrata apenas partes do BD, de acordo o interesse de um determinado grupo de
usuários, por meio dos esquemas externos, denominado de visões. Essa possibilidade de se ter
múltiplas visões particulares dos dados é, também, um recurso de segurança dos dados.
Os mapeamentos permitem que se altere um esquema em um determinado nível, sem ter que
alterar o esquema no próximo nível mais elevado. Assim, chamamos de independência lógica de
dados, a possibilidade de alterar o esquema conceitual sem ter que alterar os esquemas do nível da
visão, proporcionado pelo mapeamento externo/conceitual (veja a Figura 3). E temos a
independência física de dados, que é a propriedade de poder alterar o esquema físico sem ter
que alterar os esquemas conceituais, proporcionado pelo mapeamento conceitual/interno
(veja a Figura 3).
Outra característica importante dos SGBDs é a possibilidade de recuperação de falhas, que é
realizada por meio do subsistema de backup e recuperação. Esse subsistema garante a existência de
cópias, no caso de perda de dados, e restaura o estado do sistema após a execução parcial de uma
transação. Nesse caso, ele assegura a restauração da situação do BD a um estado consistente e
íntegro, garantindo a execução total ou cancelamento total da(s) transação(ões).
Os SGBDs, segundo Elmasri e Navathe (2018), possuem um módulo de processamento e otimização
de consultas que, com base nas estruturas de armazenamento existentes, escolhe um plano de
execução eficiente para cada consulta demandada. Um plano de execução é uma sequência de
operações que é usada para realizar uma consulta no BD.
Ramakrishnan e Gehrke (2011) apontam, dentre as vantagens do uso dos SGBDs, o acesso eficiente
e seguro aos dados, por meio da imposição de restrições de integridade de dados. As
restrições de integridade são as regras do ambiente de informação observado (contexto), que
precisam ser contempladas no banco de dados. De forma geral, podemos dizer que são limitações
impostas aos dados para que o banco de dados conserve o seu estado válido. Como exemplo,
retornemos ao nosso cenário da clínica médica, e suponha as seguintes regras e seus respectivos
tipos de restrições:
Regra: o código do CRM (Conselho Regional de Medicina) é um número com, no máximo, cinco
dígitos.
Arquitetura de três esquemas.
https://cead.uvv.br/conteudo/wp-content/uploads/2021/07/Screenshot_3-5.png
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores deBancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 7/15
Restrição de integridade a ser aplicada: restrição de domínio (quando um atributo é associado a
um determinado conjunto de valores). Declarar o atributo ‘CRM’ como número inteiro com valores
entre 0 e 99999.
 
Regra: para agendar uma consulta, o paciente deve ter um cadastro na clínica.
Restrição de integridade a ser aplicada: restrição de integridade referencial (um atributo em
uma tabela-A que referencia uma tabela-B precisa existir nessa tabela-B). Declarar o atributo ‘CPF’
da tabela ‘Consulta’ como chave-estrangeira (fazendo referência à tabela ‘Paciente’).
Outra vantagem é o controle de concorrência, que permite múltiplos usuários acessarem o
banco de dados ao mesmo tempo, garantindo que as transações concorrentes operem de maneira
correta e eficiente.
3. Linguagens de acesso e gerenciamento de
um sgbd
Todas as consultas e atualizações realizadas em um BD devem ser especificadas em uma linguagem
no SGBD.
Linguagens usadas para definição de dados:
A linguagem utilizada para criação dos esquemas conceitual (lógico) e interno (físico), na grande
maioria dos SGBDs, é a Data Definition Language - DDL (linguagem de definição de dados). De
acordo com Silberschatz, Korth e Sudarshan (2020), ela permite definir os esquemas de cada tabela
(estrutura de armazenamento), os tipos de valores de cada atributo, as restrições de integridade, os
índices, a segurança e autorizações de acesso.
Elmasri e Navathe (2018), relatam que em alguns SGBDs a DDL é utilizada apenas para definição
do esquema conceitual (lógico), enquanto a Storage Definition Language - SDL (linguagem de
definição de armazenamento) é utilizada para definir o esquema interno (físico).
Uma terceira linguagem, a View Definition Language - VDL (linguagem de definição de visões) é
utilizada para definir o esquema externo, ou seja, as diversas visões dos usuários. Contudo, na
grande maioria dos SGBDs, a DDL é utilizada para a criação dos três esquemas.
 
Linguagens usadas para a manipulação dos dados
A recuperação, inserção, remoção e modificação dos dados são realizadas por meio da Data
Manipulation Language - DML (linguagem de manipulação de dados). Conforme Silberschatz,
Korth e Sudarshan (2020), existem dois tipos de linguagem de manipulação de dados: as DMLs
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 8/15
procedurais, que necessitam que os usuários especifiquem quais dados são necessários e como
obtê-los; e as DMLs declarativas, que necessitam apenas que o usuário especifique quais dados
são necessários.
 
Structured Query Language – SQL
Efetivamente, na maioria dos SGBDs, essas linguagens fazem parte de uma única linguagem. Como
exemplo, temos a Structured Query Language – SQL (linguagem de consulta estruturada) que foi
padronizada para os bancos de dados relacionais pela American National Standards Institute -
ANSI e a International Standards Organization – ISO. A Figura 04 ilustra a estrutura das
linguagens que compõem a SQL e seus principais comandos.
Além de agrupar as linguagens DML e DDL, conforme mostrado na Figura 04, fazem parte da
estrutura da SQL a Data Control Language - DCL (linguagem de controle de dados), e a Data
Transaction Language – DTL (linguagem de transação de dados). De acordo com Elmasri e
Navathe (2018), a DCL permite atribuir ou remover tipos de permissões a um ou mais usuários.
Essas permissões são autorizações concedidas pelo SGBD para leitura, inclusão, remoção ou
atualização de dados em uma relação (tabela) ou em uma visão (tabela virtual). Enquanto a DTL é
responsável pela confirmação ou reversão de uma transação.
Exemplos do uso da SQL:
 
 
- Criação da tabela Medico e alteração da tabela Paciente (adição do atributo cidade):
- Mostrar todas as consultas marcadas para o paciente “João Paulo”
Resumo dos comandos da SQL por sublinguagens.
https://cead.uvv.br/conteudo/wp-content/uploads/2022/08/substituicao1-7-768x202.png
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 9/15
4. Componentes e arquiteturas dos sgbds
De acordo com Silberschatz, Korth e Sudarshan (2020), os componentes funcionais de um SGBD
podem ser divididos em gerenciador de armazenamento, componentes do processador de
consulta e componente de gerenciamento de transações. A Figura 05, mostra de forma
resumida esses componentes.
O gerenciador de armazenamento é o responsável por armazenar, recuperar e atualizar os
dados no BD. Seus componentes incluem: gerenciador de autorização de integridade, gerenciador
de transação, gerenciador de arquivos e gerenciador de buffer.
O processador de consultas é o responsável por interpretar e traduzir as instruções DML para o
mecanismo de avaliação de consulta executá-las a um menor custo possível. Ele compreende os
seguintes componentes: interpretador DLL, compilador DML e mecanismo de avaliação de
consulta. 
O gerenciador de transações é o responsável por garantir que, mesmo na ocorrência de falhas
do sistema, o BD permaneça em estado consistente (correto). Além disso, ele garante que as
transações concorrentes sejam efetuadas sem conflitos. O gerenciador de transação consiste no
gerenciador de recuperação e no gerenciador de controle de concorrência.
Segundo Elmasri e Navathe (2018), “uma transação é um programa em execução que forma uma
unidade lógica de processamento de dados”. As transações devem possuir as propriedades de
Atomicidade, Preservação da Consistência, Isolamento e Durabilidade, denominada ACID. 
 
A atomicidade exige que a uma transação seja toda executada ou que nada seja executado. O
gerenciador de recuperação é o responsável por manter a atomicidade da transação.
Arquitetura simplificada de um SGBD
https://cead.uvv.br/conteudo/wp-content/uploads/2022/08/substituicao1-8-768x162.png
https://cead.uvv.br/conteudo/wp-content/uploads/2021/07/Screenshot_6-5.png
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 10/15
A preservação da consistência deve assegurar que o BD não perca sua consistência após a
execução da transação. Um BD consistente significa que ele atende todas as restrições de
integridades impostas pelo programador ou pelo SGBD.
O isolamento não permite que a transação seja interferida ou que interfira na execução de
outra. Essa propriedade é imposta pelo gerenciador de controle de concorrência.
A durabilidade, cuja responsabilidade é do gerenciamento de recuperação, deve garantir que
as modificações realizadas no BD pela transação, não se percam por alguma falha.
 
4.1 Arquitetura dos SGBDs
Como dito inicialmente, as arquiteturas dos SGBDs evoluíram de acordo com a evolução dos
sistemas computacionais. Nessa seção vamos falar um pouco mais sobre essas arquiteturas.
Na arquitetura centralizada, os bancos de dados são executados em um único sistema de
computador. Inicialmente, eram baseadas em mainframes e grande parte dos usuários acessaram o
sistema por meio de terminais de computador que não tinham poder de processamento. O esquema
dessa arquitetura é ilustrado na Figura 6.
No ambiente com a arquitetura cliente-servidor tem-se servidores especializados (de arquivos,
impressão, web, correio-eletrônico, etc.) que compartilham seus recursos com as estações de
trabalho, ou seja, os clientes. As máquinas clientes oferecem aos usuários as interfaces adequadas
para que possaminteragir com os servidores, além de capacidade de processamento local para
executar as aplicações.
Uma arquitetura cliente-servidor bastante simples é que distribui seus componentes apenas entre o
cliente e o servidor, chamado de duas camadas. Normalmente, os servidores são chamados de
servidor de consulta ou servidor de transação, e nos SGBDs relacionais é também
denominado de servidor SQL. A Figura 7 ilustra essa arquitetura.
Arquitetura centralizada.
Arquitetura cliente-servidor lógica de 2 camadas.
https://cead.uvv.br/conteudo/wp-content/uploads/2022/08/substituicao1-9-768x443.png
https://cead.uvv.br/conteudo/wp-content/uploads/2021/07/Screenshot_8-3.png
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 11/15
A arquitetura de três camadas possui uma camada intermediária entre o cliente e o servidor de
banco de dados, denominada servidor de aplicação ou servidor web, como mostra a Figura 8. De
acordo com Elmasri e Navathe (2018), a camada de aplicação permite que os usuários entrem com
os dados. A camada lógica de negócios lida com as regras e restrições do negócio antes de serem
encaminhadas para a terceira camada, o servidor do SGBD, ou devolvidas para o cliente. Essa
arquitetura é mais segura e possui melhor desempenho do que a de duas camadas.
Para aprofundar no tema e conhecer sobre as particularidades das arquiteturas denominadas
paralelas e distribuídas, recomendamos as seguintes leituras:
Arquitetura cliente-servidor lógica de 3 camadas com as nomenclaturas geralmente utilizadas.
RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Capítulo 22 – Banco de Dados Paralelos e Distribuídos.
In: Sistemas de Gerenciamento de Bancos de Dados. 3a. ed. Porto Alegre: McGraw-Hill,
2011.p.604-641.
ALMEIDA, F. G.; FARIN, R. M. Rede de farmácias: um estudo utilizando banco de dados distribuídos. 
Clique aqui
5. Classificação dos sgbds
Uma das formas comumente empregadas para classificar os SGBDs é em relação ao modelo de
dados utilizado. O modelo de dados comercialmente mais utilizado é o modelo de dados
relacional, que foi baseado na teoria dos conjuntos e lógica de predicados, por Codd em 1970. No
modelo relacional, os bancos de dados são representados por várias tabelas relacionadas entre si e
armazenadas como um arquivo.
https://cead.uvv.br/conteudo/wp-content/uploads/2022/08/substituicao1-10.png
https://semanaacademica.org.br/system/files/artigos/revista_cientifica_bdd_rede_de_farmacias14ago.pdf
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 12/15
O modelo de dados orientado a objetos descreve o banco de dados usando os conceitos de
objetos, suas propriedades e operações. Ele elevou o nível de abstração e pôde simplificar alguns
problemas do modelo relacional. Entretanto, seu uso não se tornou tão generalizado,
comercialmente, como o relacional. Por outro lado, o modelo relacional tem evoluído e incorporado
conceitos relacionados ao modelo orientado a objeto, o que fez surgir a categoria denominada
modelo objeto-relacional.
O crescimento de aplicações, cujas restrições impostas pelos modelos relacionais dificultam a
implementação de suas estruturas de dados, fez com que novos modelos fossem desenvolvidos.
Dessa forma, de acordo Elmasri e Navathe (2016), surgiram os seguintes modelos de dados:
Modelo de dados de documentos, que é baseado em JSON (Java Script Objetcr Notation)
e “armazena os dados como documentos”.
Modelo de dados chave-valor, associa uma chave a um valor que pode ser um registro ou
objeto.
Modelo de dados de grafo, onde os nós dos grafos representam os objetos e suas arestas as
relações entre os objetos.
Modelo de dados em colunas, armazena no disco as colunas de linhas que são agrupadas e,
assim, otimiza a recuperação e armazenamento de dados.
Para conhecer um pouco mais a respeito desses modelos, assista o seguinte vídeo:
Além desses modelos, alguns SGBDs têm empregado o modelo XML que utiliza estruturas de
árvores hierárquicas onde os dados são representados como elementos e podem ser aninhados para
criar estruturas complexas. Alguns SGBDs relacionais têm adicionado, também, esses recursos.
Considerados como modelos de dados legados, os modelos de dados hierárquico e em rede
foram os primeiros a serem concebidos, como comentamos na introdução desta lição. No modelo
hierárquico os dados eram organizados como uma árvore invertida, onde cada entidade tinha
apenas um pai, mas podia ter vários filhos e, no topo da hierarquia, existia uma entidade chamada
de raiz, como mostra a Figura 09(a). O modelo de dados de rede, considerado como uma
extensão do modelo hierárquico, tinha as entidades organizadas como um grafo, no qual algumas
entidades poderiam ser acessadas por diversos caminhos, conforme ilustra a Figura 09 (b).
CODD, E. F.; A Relational Model of Data for Large Shared Data Banks. Communications of the
ACM. v. 13, n. 6, 1970.
Clique aqui
https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 13/15
Os SGBDs também podem ser categorizados de acordo com o número de dados suportados, sendo
monousuários, quando o sistema pode ser acessado por apenas um usuário por vez, ou
multiusuários, quando permitem o acesso de vários usuários simultaneamente.
Quanto ao número de locais distribuídos, eles podem ser centralizados, onde todo o sistema está
armazenado em um único computador, ou distribuídos, onde o SGBD encontra-se distribuído em
vários locais e conectados a uma rede de computadores. Eles podem utilizar um mesmo software de
SGBD em todos os locais, sendo homogêneos, ou podem usar diferentes softwares de SGBD em
cada local, heterogêneos.
Outras classificações podem ser encontradas nas seguintes referências:
a) Modelo de dados hierárquico de uma universidadeb) Modelo de dados de rede de uma universidade
ELMASRI, Ramez; NAVATHE, Shamkant B. Classificação dos Sistemas Gerenciadores de Banco de
Dados. Sistemas de Banco de Dados. 7a. ed. São Paulo: Editora Pearson, 2018, p.47-50.
6. Conclusão
Nesta lição, vimos a importância dos SGBDs para o gerenciamento de informações e que a escolha
da sua arquitetura dependerá da demanda dos programas de aplicação. Vimos também que, as
arquiteturas dos SGBDs têm evoluído similarmente às arquiteturas dos sistemas computacionais,
passando de um único software integrado e monousuário a um software modular e distribuído.
Os primeiros SGBDs introduziram os modelos de dados em rede e hierárquico, seguindo o modelo
de dados relacional que é o mais utilizado até os dias de hoje, ainda que as novas tecnologias
possibilitem o gerenciamento de dados não estruturados.
https://cead.uvv.br/conteudo/wp-content/uploads/2021/07/Screenshot_10-3.png
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 14/15
As principais características e benefícios dos SGBDs incluem a abstração de dados, o suporte à
múltiplas visões dos dados, a independência entre os dados e a aplicação, a recuperação das falhas
do sistema, dentre outras. As linguagens utilizadas nos SGBDs se resumem na DDL e DML, sendo
que a SQL é a linguagem padrão para os SGBDs relacionais e que contém todas as funcionalidades
das demais.
Os componentes funcionais dos SGBDs podem ser divididos em: gerenciador de armazenamento,
processador de consultas e gerenciador de transações.Também exploramos sobre as arquiteturas
dos SGBDs: a centralizada, a cliente-servidor de uma ou mais camadas; e, por fim, abordamos
sobre as formas de classificar os SGBDs.
7. Referências
ALMEIDA, F. G.; FARIN, R. M. Rede de farmácias: um estudo utilizando banco de dados
distribuídos. Disponível em:
https://semanaacademica.org.br/system/files/artigos/revista_cientifica_bdd_rede_de_farmacias1
4ago.pdf
BACHMAN C. W., The Origin of the Integrated Data Store (IDS): The First Direct-Access DBMS.
IEEE Annals of the History of Computing, v. 31, n. 4, 2009. pp. 42-54. doi:
10.1109/MAHC.2009.110.
BACHMAN, C. W. Data structure diagrams. ACM SIGMIS Database: the DATABASE for Advances
in Information Systems. v.1, n.2, 1969. pp 4-10. https://doi.org/10.1145/1017466.1017467
BERG, Kristi L.; SEYMOUR, Tom; GOEL, Richa. History of databases. International Journal of
Management & Information Systems. v.17, n.1, 2013. Disponível em:
https://clutejournals.com/index.php/IJMIS/article/view/7587/7653 Acessado em: 07 jun. 2021.
DATE, C.J. Introdução a Sistemas de Banco de Dados. 8a. ed. Rio de Janeiro: Elsevier, 2003.
ELMASRI, Ramez; NAVATHE, Shamkant B. Fundamentals of Database Systems. 7th edition.
Hoboken: Pearson Education, 2016.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de Dados. 7a. ed. São Paulo:
Editora Pearson, 2018.
07/08/23, 20:08 Arquiteturas de Sistemas Gerenciadores de Bancos de Dados (SGBD)
https://ceadgraduacao.uvv.br/conteudo.php?aula=arquiteturas-de-sistemas-gerenciadores-de-bancos-de-dados-sgbd&dcp=arquitetura-de-dados-relacionais-i&topico=2 15/15
PATRICK, Robert L. IMS @ Conception. IEEE Annals of the History of Computing, v. 31, n. 4,
2009, pp. 62-65. doi: 10.1109/MAHC.2009.102.
RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Sistemas de Gerenciamento de Bancos de Dados.
3a. ed. Porto Alegre: McGraw-Hill, 2011 (ebook).
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Modelo Relacional. In: Sistema de
banco de dados. 6. ed. Rio de Janeiro: Elsevier, 2006, pp.25-31.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 7. ed.
- Rio de Janeiro: LTC, 2020 (ebook).
YOUTUBE. Canal TI. (2018). NoSQL em 5 minutos. 4:53 Disponível em:
https://youtu.be/DnfcIuqa0xo