01 Banco de Dados I

Parte 1
Banco de Dados e
Modelagem de Dados
tema1
Banco de Dados
e Sistema
Gerenciador de
Banco de Dados
Neste tema vamos conhecer os conceitos ini-
ciais sobre banco de dados, sua importância
e as principais características dos Sistemas
Gerenciadores de Banco de Dados (SGBD),
analisando os elementos que compõem a sua
arquitetura e como eles auxiliam os desenvol-
vedores de softwares.
Depois da leitura deste tema verificaremos que

os SGBDs consistem em um elemento funda-
mental no dia a dia das empresas e como eles
devem ser utilizados na construção de siste-
mas computadorizados.
1.1
EVOLUÇÃO DOS SISTEMAS DE BANCO DE DADOS
O conceito de banco de dados não está restrito a área da tec-

nologia da informação. Ele está presente no nosso dia a dia seja em
forma digital ou em elementos do mundo real. Segundo Elmasri e
Navathe (2005, p.4), um banco de dados é uma coleção lógica e coe-
rente de dados com algum significado inerente. Podemos considerar
que as palavras que formam esta página representam um banco de
dados ou que as informações cadastrais dos alunos de uma grande
universidade também estão contidas em outro banco de dados. Eles
podem variar de tamanho e de complexidade, ou seja, podemos ter
um banco de dados das pessoas que formam o seu catálogo telefônico
e, em outro extremo, o banco de dados do Google. Você já imaginou
a quantidade de informações armazenadas pelo Google? Na verdade
não temos esta informação de forma exata, apenas estima-se que a
base de dados no Google é formada por mais de 1.000.000 de servi-
dores espalhados por todo o mundo.
Os bancos de dados podem ser trabalhados de forma manual

ou automatizada (computadorizada). Os manuais necessitam da pre-
sença física do homem para serem organizados e consequentemente
tenham informações incluídas, alteradas, excluídas e consultadas. Um
exemplo de um banco de dados manual é uma biblioteca pública onde
é necessário um bibliotecário com conhecimento técnico para realizar
a organização do acervo, seja incluindo ou descartando livros. Quando
se precisa de um livro, é necessário andar por algumas estantes a fim
de encontrar o título. Sabemos que às vezes encontrar em um livro em
uma biblioteca não é uma tarefa tão fácil!
O banco de dados computadorizado armazena dados digitais,

ou seja, bytes. A organização das informações é feita por softwares
16
Banco de Dados I
que também possuem a responsabilidade de localizar a informação

quando necessário. Como já citado nessa seção, os dados dos alu-
nos de uma grande universidade podem formar um banco de dados
computadorizado. Ou seja, todas as informações de notas, disciplinas,
professores, entre outras ficam armazenadas em um computador ao
invés de pastas organizadas em grandes salas. Armazenar as infor-
mações em forma de bytes traz vários benefícios. Entre eles:
DD Economia de espaço físico: poderemos substituir uma sala

repleta de pastas por um único computador com todas as
informações;
DD Organização: não serão necessárias várias pessoas para

organizar as pastas, a organização é feita automaticamente
pelo computador;
DD Rapidez na localização da informação: para encontrar uma

informação em um banco de dados manual, a pesquisa deve
ser feita por pasta até encontrar a informação. Nos bancos
de dados computadorizados, a pesquisa é feita pelo compu-
tador em uma velocidade bem superior à pesquisa manual.
A justificativa para esta velocidade na pesquisa será vista na
próxima seção;
DD Redução na quantidade de papel: o armazenamento digital

reduz a quantidade de papel gerado, uma vez que a utiliza-
ção do papel só ocorre quando se faz necessário extrair al-
guma informação do banco de dados para impressão.
O objetivo deste livro é estudar os bancos de dados computa-

dorizados, sua estrutura e a forma como podemos utilizá-los no de-
senvolvimento de softwares. A partir deste momento iremos nos re-
ferir a banco de dados computadorizados como simplesmente banco
de dados.
17
Tema 1
Banco de Dados e Sistema
Gerenciador de Banco de Dados
Sistema Gerenciador de Banco de Dados
Um banco de dados consiste basicamente em um conjunto de

arquivos organizados no sistema de arquivo de um sistema operacio-
nal. Para que estes arquivos possam ser manipulados (sejam feitas
inclusão, alterações, exclusão e consultas nos dados) são necessários
softwares. Por exemplo: os dados contidos em um arquivo de uma
planilha eletrônica necessitam de um software capaz de interpretar
este arquivo para poder manipulá-lo. Sem este software o dado fica
inacessível.
Desta forma, durante o desenvolvimento de um software, o pro-

gramador terá a tarefa de implementar, além das funcionalidades nor-
mais de seu software, o código necessário para manipular os arquivos
que compõe o banco de dados de sua aplicação. A figura 01 ilustra o
relacionamento do software com os arquivos de seu banco de dados.
Interação software com arquivos do banco de dados – Sem SGBD.

18
Banco de Dados I
Durante a implementação da lógica de manipulação dos arqui-

vos, o programador além de se preocupar com as rotinas de inclusão,
alteração, exclusão e consulta de dados, também deve ter atenção a
outros fatores que são fundamentais para o bom funcionamento do
software (ELMASRI; NAVATHE, 2005). São eles:
D Segurança: geralmente um banco de dados é acessado por

várias pessoas, desta forma o software deve garantir que
informações específicas possam ser acessadas apenas por
usuários autorizados;
D Integridade: falaremos muito nesta palavra. O seu propó-

sito no contexto de banco de dados é garantir que os dados
armazenados estejam de acordo com as regras definidas
inicialmente para ele. Por exemplo, a média de um aluno não
pode ter valores negativos ou o produto não pode ser ven-
dido se seu estoque for 0. Quando um dado está em con-
formidade com as regras definidas, também dizemos que
o mesmo está consistente. Esta é outra palavra que vocês
terão contato durante toda a disciplina;
D Atomicidade: geralmente uma funcionalidade do software

envolve várias operações de manipulação de dados no ban-
co de dados. Por exemplo: para realizar a transferência R$
100,00 da conta-corrente A para B, teríamos os seguintes
passos:
Verificar se saldo da conta A é suficiente;
Debitar R$ 100,00 da conta A;
Creditar R$ 100, 00 da conta B.

19
Tema 1
Se tudo corresse bem, teríamos, ao final da operação, o crédito e

o débito nas contas deixando os valores consistentes. Mas o que acon-
teceria se após o passo 2 e antes do passo 3 faltasse energia? Com
certeza o cliente da conta A ficaria no prejuízo, pois sua conta teve um
valor debitado, mas a conta B não teve o crédito. O programador deve
garantir que se uma das operações não ocorra toda a transação deve
ser desfeita de forma que os dados não fiquem inconsistentes.
Transação: No contexto de banco de dados,

uma transação representa um conjunto de
operações sobre os dados que juntas repre-
sentam apenas uma na visão do usuário.
D Concorrência: como o banco de dados pode ser acessado

por vários usuários, nada impede que estes possam realizar
operações sobre os mesmos dados ao mesmo instante. Este
acesso simultâneo, que também chamamos de acesso con-
corrente, pode gerar dados inconsistentes ao final das tran-
sações. O que aconteceria se duas pessoas fizessem manipu-
lações no saldo da conta A ao mesmo tempo? Provavelmente
o saldo da conta A ficaria inconsistente. Na seção 1.4 tratare-
mos mais sobre este assunto, explicando situações indesejá-
veis que podem ocorrer devido a esta forma de acesso.
Além destes fatores, o programador terá que solucionar mais

duas situações que agregam trabalho durante o desenvolvimento do
software. A primeira situação, citada por Silberschatz, Korth, e Sudar-
shan (1999, p. 2) como “Dificuldade de acesso aos dados” diz respei-
20
Banco de Dados I
to à complexidade de trabalhar com os arquivos. O programador deve

implementar toda a lógica que trate da inclusão, alteração, exclusão e
consulta dos dados dentro dos arquivos. Outra situação, citada por Sil-
berschatz, Korth, e Sudarshan (1999, p. 3) como “Isolamento de dados”,
refere-se à dificuldade na manutenção dos arquivos, pois qualquer mu-
dança na estrutura dos arquivos (mudança de diretório, por exemplo)
afetaria o programa de forma que o mesmo deveria ser reescrito.
Como um banco de dados é composto por vários arquivos, o

programador deve-se preocupar em manipular arquivos que corres-
pondem aos dados corretos e em garantir a não repetição de infor-
mação entre estes diversos arquivos, comumente chamada de redun-
dância no contexto de banco de dados.
Diante de todos estes aspectos e problemas, os programadores

adicionaram ao seu trabalho uma complexidade maior para desenvol-
ver seu software, além de compartilhar a sua concentração com ele-
mentos que não dizem respeito às funcionalidades do produto final.
Isso, inevitavelmente, elevou o tempo e o custo do software.
Os Sistemas Gerenciadores de Banco de Dados (SGBD) surgi-

ram motivados por estas questões. O objetivo dos SGBDs é facilitar o
trabalho do programador quanto à manipulação dos dados. Conforme
Silberschatz, Korth, e Sudarshan (1999, p. 17), a meta básica de um
SGBD é proporcionar um ambiente conveniente e eficiente para recu-
peração e armazenamento de informações.
O SGBD é uma parte do que iremos chamar neste livro de Siste-

ma de Banco de Dados, que também inclui a aplicação desenvolvida
(que vamos chamar a partir deste momento de aplicação cliente) e o
banco de dados.
O SGBD está localizado entre a aplicação cliente e o banco de

dados e todo acesso aos dados deve ser realizado através dele. Por
21
Tema 1
estar entre a aplicação cliente e o banco de dados, o SGBD simplifica a

forma de acesso aos dados e resolve os problemas já citados. A figura
02 exibe a arquitetura de um sistema de banco de dados.
Arquitetura básica de um sistema de banco de dados.
Na seção 1.2 faremos um estudo mais detalhado sobre SGBD,

analisando sua arquitetura, componentes e importância para o desen-
volvimento de aplicações.
LEITURA COMPLEMENTAR
D DATE, Christopher J. Introdução a Sistemas de Banco de Dados.
8. ed. Rio de Janeiro: Campus, 2004.
Os conceitos e elementos do sistema de banco de dados são abor-

dados com mais detalhes no capítulo 1 deste livro. Nesta obra o au-
tor justifica a necessidade e importância de um Sistema de Banco de
Dados fazendo um comparativo com os dos métodos tradicionais de
armazenamento.
22
Banco de Dados I
D SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S.

Sistema de bancos de dados. 3. ed. São Paulo: Makron books,
1999.
No primeiro capítulo deste livro você terá maiores detalhes sobre os

problemas no desenvolvimento de software sem um SGBD, que en-
volvem: redundância de dados, dificuldade no acesso, isolamento de
dados, problemas de integridade, problemas de atomicidade, anoma-
lias de acesso concorrente e problemas de segurança.
PARA REFLETIR
Nesta seção citamos Atomicidade como uma das características que
deve ser garantida pelos programadores no desenvolvimento de apli-
cações que não utilizam SGBD. Reúna-se com seus colegas para dis-
cutir a importância deste conceito e o porquê dele receber este nome.
23
Tema 1
1.2
SISTEMA GERENCIADOR DE BANCO DE DADOS
Existem várias definições para um SGBD. Elmasri e Navathe

(2005, p.4) definem como uma coleção de programas que permitem
ao usuário criar e manter um banco de dados. Já Silberschatz, Korth,
e Sudarshan (1999, p.4) como uma coleção de arquivos e programas
inter-relacionados que permitem ao usuário acesso para consultas e
alterações desses dados.
Como já citado no conteúdo 1.1, o SGBD tem a função de facili-

tar e otimizar o trabalho de manipular dados, auxiliando na definição,
construção e manutenção destes dados.
O SGBD não tem uma finalidade específica, é um software de

propósito geral, ou seja, pode ser utilizado para armazenar dados de
uma grande universidade, de um grande grupo de lojas de varejo, en-
tres outras organizações, cabendo aos profissionais da área de tec-
nologia da informação definir a estrutura e quais dados deverão ser
armazenados em cada banco de dados de forma a ter a melhor repre-
sentatividade da realidade.
Se quiséssemos resumir as funções disponibilizas por um SGDB po-

deríamos fazê-lo em 6 palavras: definição, construção, manipulação, com-
partilhamento, proteção e manutenção (ELMASRI; NAVATHE, 2005).
D Definição: oferecer recursos que facilitam a definição do

banco de dados, que inclui: definição dos dados que serão
armazenados, seus tipos e restrições;
D Construção: permitir o armazenamento do banco de dados

em algum tipo de mídia;
24
Banco de Dados I
DD Manipulação: disponibilizar recursos que facilitem e otimi-

zem as consultas e alterações dos dados;
DD Compartilhamento: permitir que o banco de dados possa

ser acessado por vários usuários sem gerar inconsistência
nos dados;
DD Proteção: proteger o banco de dados de possíveis falhas e

de acessos não autorizados;
DD Manutenção: manter os dados por um longo período de tempo.
No transcorrer deste tema veremos os elementos do SGBD que

garantem estas funções.
Arquitetura de um SGDB
A fim de disponibilizar as funções citadas anteriormente, foi
proposta uma arquitetura básica de implementação dos SGBDs. Em-
bora esta arquitetura não seja seguida de forma rigorosa por todos os
fabricantes, ela se faz presente na maioria dos SGBDs atuais.
Denominada Arquitetura de Três-Esquemas, ela está baseada

na divisão do SGBD em três níveis: Nível Externo, Nível Conceitual e
Nível Interno (ELMASRI; NAVATHE, 2005) (SILBERSHATZ; KORTH;
SUDARSHAN, 1999). O Principal benefício desta arquitetura é ofere-
cer uma visão abstrata dos dados armazenados. Isto é, esconder dos
usuários toda a complexidade de armazenamento, consulta e manu-
tenção dos dados, dando ao usuário a possibilidade de trabalhar de
uma forma mais simples e produtiva.
25
Tema 1
Agora vamos entender melhor estes níveis e como eles garan-

tem esta abstração.
DD Nível Físico: também chamado de interno, descreve os

detalhes dos arquivos que compõe o banco de dados. São
geralmente estruturas complexas formadas por um ou mais
arquivos do sistema operacional. Este nível é acessado por
usuários especialistas no SGBD, conhecidos como DBA (ve-
remos detalhes sobre cada tipo de usuário mais na frente);
DD Nível Conceitual: geralmente acessado pelos programa-

dores e também conhecido por lógico, é responsável por
mapear as informações dos arquivos do nível físico em uma
estrutura de fácil entendimento. A visão oferecida pelo nível
conceitual é chamada de Modelo de Dados. Existem vários
tipos de Modelos de Dados que foram propostos ao longo do
tempo, entre eles podemos destacar: Relacional, Rede e Hie-
rárquico. Os modelos de Rede e Hierárquico já não são tão
utilizados e por isso não serão tratados neste livro. O Mode-
lo Relacional é o mais comum entre os SGBDs atuais e está
baseado na transformação dos bytes dos arquivos do nível
físico em tabelas (linhas e colunas), como ilustra a figura 03.
Estaremos estudando de forma mais detalhada o Modelo de
Dados Relacional no tema 2;
26
Banco de Dados I
Mapeamento do nível interno para o modelo de dados relacional.
DD Nível Externo: na maioria das vezes os usuários não neces-

sitam ter acesso a todo o banco de dados representado no
nível conceitual. O nível externo, também conhecido como
Visão, oferece a possibilidade de ocultar parte do banco de
dados, liberando apenas fragmentos significativos para de-
terminado grupo de usuário. Por exemplo, as secretárias de
uma universidade necessitam saber apenas informações
acadêmicas dos alunos, porém as informações financeiras
dos mesmos só devem ser acessadas pelos usuários res-
ponsáveis pela parte financeira da instituição. Embora todas
as informações acadêmicas e financeiras estejam no mes-
mo banco de dados, são oferecidas visões diferentes para
determinados usuários, gerando vários bancos de dados
“virtuais”. Além de garantir a segurança da informação para
acessos específicos, a separação de visões também sim-
27
Tema 1
plifica a manipulação das informações no banco de dados

(SILBERSHATZ; KORTH; SUDARSHAN, 1999). A definição
do nível externo não é obrigatória, na verdade, em muitos
casos o acesso é feito direto ao nível conceitual, por oferecer
uma maior simplicidade de definição de estrutura uma vez
que se tem um nível a menos para se trabalhar. A decisão de
se utilizar ou não o nível externo é dos profissionais envolvi-
dos no projeto e que devem avaliar a organização do banco
de dados e o seu tamanho para decidir ou não pela criação
de níveis externos.
A arquitetura três-esquemas é ilustrada pela figura 04.
Visão Geral de uma Arquitetura Três-Esquemas.

28
Banco de Dados I
Catálogo
Uma característica fundamental dos SGBD é que, além de arma-

zenar os dados da aplicação, também é feito o armazenamento do que
chamamos de metadados. Metadados são informações que descre-
vem os níveis da arquitetura três-camadas. São dados mantidos au-
tomaticamente pelo SGBD no local chamado de Catálogo e possuem
informações como: estrutura dos arquivos que formam o nível físico,
tipos dos dados representados no nível conceitual e seus relaciona-
mentos, definições dos níveis externos, entre outros. Desta forma,
toda vez que há uma alteração na definição dos níveis, os metadados
são atualizados automaticamente, de forma a sempre representar a
estrutura do banco.
O catálogo é utilizado para o SGBD realizar o mapeamento entre

os níveis e para o DBA realizar análise das estruturas do SGBD a fim
de tomar decisões de gerência da base de dados.
Mapeamento
Ao implementar a arquitetura três-esquemas, o SGBD é respon-
sável por fazer o mapeamento entre os níveis. Quando um usuário faz
uma solicitação de recuperação de informação, o SGBD realiza o mape-
amento do nível externo para o nível conceitual e depois do nível con-
ceitual para o nível físico onde realmente encontram-se as informações,
tudo isso utilizando as informações armazenadas do catálogo.
Todo este trabalho é transparente ao usuário, é o que chama-

mos de abstração, pois toda a complexidade de acesso aos arquivos
para obter a informação como também a visualização da estrutura do
banco de dados é simplificada para um modelo onde os usuários sin-
29
Tema 1
tam-se mais a vontade para trabalhar. Esta abstração tem um grande

impacto na produtividade dos profissionais, pois retiram deles uma
complexidade que se teria caso fossem trabalhar diretamente com os
arquivos físicos. Afinal, se fosse para você escolher entre acessar di-
retamente os arquivos do sistema operacional para obter as informa-
ções dos professores da instituição ou acessar uma tabela com linhas
e colunas contendo estas informações, o que você escolheria?
Você agora deve estar pensando o seguinte: “Tenho uma visão

simplificada dos dados, mas como vou acessar estes dados? Se o
acesso a estes dados mesmos com a visão simplificada for difícil, não
ajudará muito”. Começaremos a dar esta reposta conteúdo 1.4 deste
tema e a complementaremos nos temas 3 e 4, quando apresentare-
mos a linguagem SQL, responsável pela manipulação de dados nos
SGBDs.
Independência de Dados
Segundo Elmasri e Navathe (2005, p. 23), independência de da-
dos é a capacidade de mudar a definição de um determinado nível sem
que ocorram alterações da estrutura no nível imediatamente superior.
Em determinadas situações, é necessário realizar alterações no

nível físico para, por exemplo, corrigir problemas de eficiência na ma-
nipulação de dados ou para realizar algum tipo de manutenção, como
por exemplo, mover os arquivos para outro disco rígido. O SGBD deve
garantir que as mudanças realizadas no nível físico não afetem o nível
conceitual e consequentemente o nível externo, de forma que os pro-
gramas desenvolvidos para interagir com estes níveis não necessitem
sofrer alteração. Existem dois tipos de independência de dados:
30
Banco de Dados I
D Independência lógica: é a capacidade de alterar o nível con-

ceitual sem afetar o nível externo ou os programas. Apesar
de ser uma independência possível, ela, em alguns momen-
tos, apresenta-se difícil de ser obtida, pois existe um vínculo
grande dos programas com o nível conceitual;
D Independência física: consiste em realizar alterações no ní-

vel físico sem afetar o nível lógico. Esta independência na
maioria das vezes é possível, pois não depende de fatores
externos, o SGBD é totalmente responsável por esta inde-
pendência. Geralmente mudanças de estrutura são neces-
sárias para corrigir problemas de desempenho nas consul-
tas e alterações dos dados. Esta operação é realizada por
profissionais especialistas no SGBD e que possuem total
conhecimento sobre o nível interno.
Neste conteúdo nos concentramos no principal benefício do

SGBD, ou seja, oferecer uma visão simplificada do banco de dados.
Nos demais conteúdos veremos detalhes de outros benefícios dos
SGBDs e alguns de seus componentes.
D ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de
Dados. 4. ed. São Paulo: Pearson Brasil, 2005.
No capítulo 1 deste livro leia a seção que fala sobre as vantagens da

utilização do SGBD. Você terá mais informações sobre as funcionali-
dades do SGBD que acabamos de ver neste conteúdo.
31
Tema 1

O segundo capítulo deste livro fala, entre outros tópicos, sobre a ar-
quitetura básica dos SGBDs. Apesar de já termos tratado sobre este
assunto, é interessante observar a abordagem do autor sobre este as-
sunto.
PARA REFLETIR
Vimos que o catálogo é importante para que o SGBD possa realizar os
mapeamentos necessários entre os níveis. Ou seja, toda vez que algu-
ma operação de manipulação de dados for realizada deve ser feito um
acesso ao catálogo para viabilizar os mapeamentos. Este acesso cons-
tante ao catálogo não poderia comprometer a velocidade de recupe-
ração das informações? Discuta com seus colegas sobre esta questão.
Lembre-se dos benefícios da arquitetura três-esquemas!
32
Banco de Dados I
1.3
ARQUITETURA DE APLICAÇÕES COM SISTEMAS
GERENCIADORES DE BANCO DE DADOS
As aplicações que envolvem banco de dados possuem uma

grande variação de tamanho e complexidade. Estas variações ocor-
rem em virtude das diferenças existentes entres os tipos de aplica-
ções desenvolvidas. Por exemplo, uma aplicação que armazene a
agenda telefônica de uma pessoa possui um nível de complexidade
baixo e provavelmente não passará dos 10 megabytes de dados. Pela
complexidade da aplicação, a utilização do SGBD não é indicada, pois
acarretará um investimento maior em hardware e além de necessi-
tar de pessoas especializadas para administrar o SGBD. Além disso,
o fato da aplicação ser acessada por apenas um usuário, seus requi-
sitos não exigem o apoio do SGBD para resolver os problemas já ci-
tados (ELMASRI; NAVATHE, 2005). Por outro lado, as organizações
têm cada vez mais informatizado seus processos através da criação
de softwares específicos ou da aquisição de programas de outras
empresas. Estas aplicações caracterizam-se pela sua complexidade,
pelo seu tamanho e pelo acesso compartilhado. São aplicações que
trabalham com terabytes de dados e são acessadas por centenas e até
milhares de usuários. Para atender a estes requisitos, inevitavelmente
as aplicações devem fazer uso de um bom SGBD. O uso de um SGBD
na empresa exige uma estrutura de hardware e de pessoas para a sua
utilização. Vamos tratar agora das pessoas envolvidas na utilização do
SGBD e as responsabilidades e característica de cada uma. Muitas bi-
bliografias referem-se a estas pessoas como Atores ou simplesmente
Usuários. Mas antes de tratarmos dos autores, vamos falar dos tipos
de aplicações ou softwares que interagem com SGBDs.
33
Tema 1
Tipos de aplicações que utilizam um SGBD
Podemos dividir estas aplicações em: Aplicações desenvolvi-

das ou finais, Aplicações de apoio, Ferramentas CASE e Ferramen-
tas utilitárias.
Aplicações Desenvolvidas ou Finais

Também conhecidas como Aplicações Cliente, são aplicações
escritas em linguagens de programação de 3ª geração (ELMASRI; NA-
VATHE, 2005), como Java, cujo objetivo é atender uma demanda es-
pecífica de uma organização, como por exemplo, gerenciar o estoque
de uma grande rede de lojas varejistas. Estas aplicações serão utiliza-
das por pessoas dos mais diversos departamentos da instituição. Elas
não sabem da existência do SGBD, pois não possuem conhecimento
técnico suficiente para isso, todavia são as pessoas que mais fazem
uso da base de dados. Este tipo de aplicação tem a função de permitir
que estes usuários possam acessar a base de dados de forma fácil
oferecendo para isso interfaces simples e intuitivas. Estas aplicações
apresentam-se como formulários, relatórios, gráficos entre outros
formatos.
Aplicações de Apoio
São aplicações que auxiliam os usuários, que possuem conhe-
cimento técnico, a estar manipulando as informações no banco de
dados. Geralmente são softwares disponibilizados pelos próprios fa-
bricantes dos SGBDs e permitem que os dados possam ser acessados
através de uma linguagem de acesso ao banco dados, como SQL. Na
34
Banco de Dados I
figura 05 vocês podem ver um exemplo de um destes softwares, o

SQL Developer, que veremos com mais detalhes no tema 3 deste livro.
SQL Developer.
Os demais tipos de aplicações têm suas utilidades voltadas para

a administração do banco de dados. São utilizadas por pessoas que
não possuem interesse direto nos dados e sua maior preocupação é
na criação e manutenção da estrutura do banco de dados e no bom
funcionamento do mesmo. São as Ferramentas CASE e as Ferra-
mentas Utilitárias. As ferramentas CASE (Engenharia de Software
Auxiliada por Computador – Computer-aided Software Engineering),
são softwares que auxiliam profissionais na definição do Modelo de
Dados, já as ferramentas utilitárias auxiliam o DBA na tarefa de ad-
ministração do SGBD (ELMASRI; NAVATHE, 2005). São disponibili-
zados pelos próprios fabricantes, mas também são oferecidas por ou-
tras empresas. Elas trazem várias funcionalidades de apoio ao DBA,
como: exportação e importação de dados, backup, monitoramente de
desempenho e configuração.
35
Tema 1
Atores
Depois de termos visto os tipos de aplicações que utilizam os

bancos de dados de um SGBD, vamos identificar os papeis das pes-
soas que se conectam ao SGBD, desde o mais leigo ao mais especia-
lizado.
DD Usuários Finais: São usuários que não possuem conheci-

mento técnico e que utilizam as aplicações finais para fazer
uso do banco de dados.
DD Programadores: Escrevem as aplicações finais programan-

do operações no banco de dados que serão utilizadas pelos
usuários finais. Estas operações são chamadas de transações
customizadas (ELMASRI; NAVATHE, 2005). A principal fun-
ção dos programadores é oferecer ao usuário final uma forma
simples e rápida de realizar uma determinada ação, como por
exemplo, a reserva de quartos de um hotel.
DD Projetistas de Banco de Dados: Este profissional é res-

ponsável por identificar os dados que serão armazenados
pelo banco de dados de forma a atender aos requisitos do
usuário final. Além de identificar os dados, é de sua res-
ponsabilidade definir o modelo de dados que irá ser imple-
mentado no banco de dados observando questões como:
simplicidade, organização, não redundância, desempenho,
regras de consistência (ou regras de integridades) entre
outros pontos. Veremos mais sobre definição do modelo
de dados no tema 2.
36
Banco de Dados I
Não redundância significa evitar a repetição

de informações dentro de um banco de da-
dos.
Após a definição do modelo de dados o projetista deve trabalhar

diretamente com o DBA para implementar o modelo no SGBD.
Administradores de Banco de Dados (DBA – Database Ad-

ministrator): O DBA tem como função básica a garantia do bom
funcionamento do SGBD. Ele é o profissional responsável por fazer a
instalação e configuração do SGBD, monitorar o desempenho, criar a
política de segurança para acesso aos dados, definir e implementar as
políticas de backup, entre outras responsabilidades que garantam a
disponibilidade do SGBD. É o único profissional entre os que citamos
que trabalham no nível físico e por isso deve ter um grande conheci-
mento do SGBD que está sendo utilizado.
Vimos todos os atores que interagem com o sistema gerencia-

dor de banco de dados, sua importância e seu nível de interação com
o SGBD. A figura 06 mostra todos os atores, sua interação com os ele-
mentos de um sistema de banco de dados e com os níveis da arquite-
tura do SGBD.
37
Tema 1
Interação Usuários-SGBD.
Nos dois últimos tópicos falamos sobre os atores e as aplica-

ções que fazem uso do SGBD. Agora vamos tratar da estrutura dos
ambientes que agregam as aplicações clientes, bancos de dados e
SGBDs.
Arquitetura de Sistemas de Banco de Dados

Uma arquitetura de sistemas de banco de dados consiste nas
distribuições de seus elementos e como eles interagem. Podemos
considerar que um sistema de banco de dados é constituído por uma
aplicação cliente, por um SGBD e pelo banco de dados. Estes elemen-
tos possuem várias responsabilidades que se distribuem basicamente
em: (i) oferecer uma interface para o usuário final, (ii) escrever os pro-
gramas de manipulação de dados conforme a necessidade da orga-
nização (podemos chamar estes programas de Regras de Negócio),
38
Banco de Dados I
(iii) gerenciar os dados (feito pelo SGBD) e (iv) armazenar os dados.

Vamos discutir agora as diferentes arquiteturas que agrupam estas
funções.
Arquitetura Centralizada
Esta arquitetura caracteriza-se pelos agrupamentos dos quatro
elementos e um único software. Isso era possível através de grandes
computadores chamados de mainframes, que possuíam um grande
poder de processamento e armazenamento, mas que custavam muito
para as organizações. Apesar termos um software com todos os ele-
mentos, esta arquitetura permitia o acesso por vários usuários através
do que chamamos de terminais “burros”. São equipamentos formados
por um monitor e teclado sem qualquer poder de processamento ou
armazenamento, cujo objetivo é apenas exibir informações proces-
sadas pelo mainframe como também enviar informações para serem
processadas. Mesmo ainda existindo em grandes organizações, ele
está sendo substituído por outros que veremos na sequência deste
tema. O principal motivo para a substituição está basicamente ligado
ao alto custo de manutenção dos mainframes e, principalmente, pelo
surgimento da Internet.
Arquitetura Cliente/Servidor ou Duas Camadas

Nesta arquitetura há a separação de alguns elementos. Devido
ao barateamento dos computadores pessoais (PC), as organizações
puderam adquirir um grande número destes equipamentos. Como
são máquinas que já possuem processamento e armazenamento, foi
possível substituir os terminais “burros” por PCs fazendo que com
eles pudessem executar alguns elementos do sistema de banco de
39
Tema 1
dados, como interface do usuário e regras de negócio, deixando ge-

rência e armazenamento para o SGBD. Desta forma, podemos dividir
a arquitetura cliente/servidor em dois softwares, um com a lógica da
interface do usuário e das regras de negócio, chamado de cliente, e
outro representado pelo SGBD, chamado de servidor.
Toda vez que o software cliente necessitar de alguma informa-

ção do servidor, ele realizará uma conexão com o servidor através de
uma rede de computador e enviará os comandos necessários para
interagir com o SGBD. Nesta arquitetura, geralmente encontramos
diversos PCs (também chamados de Workstation) que executam o
software cliente e se conectam com um ou vários SGBDs. A figura 07
ilustra esta arquitetura.
Arquitetura cliente/servidor.
Além de ter o código para gerar a interface e as regras de ne-

gócio, o software cliente também deve ter a implementação da lógi-
ca para realizar o processo de conexão e transferência de informação
com o SGBD.
40
Banco de Dados I
Comparando com a arquitetura centralizada, a cliente/servidor

possui um custo reduzido uma vez que não necessita de um compu-
tador com grande poder de processamento sendo substituído por um
servidor e diversos clientes distribuindo o processamento total da
aplicação.
Arquitetura de Três Camadas

A Internet é responsável diretamente pelo surgimento deste
tipo de arquitetura. O que observamos hoje é um conjunto de apli-
cações que são acessadas pelos usuários finais através da internet
utilizando browsers, como Internet Explorer, Firefox, entre outros. A
arquitetura cliente/servidor, embora seja possível sua implementação
para aplicações na internet, oferece algumas limitações. Vamos to-
mar como exemplo um grande banco que deseja criar uma aplicação
para seus clientes acessar suas contas. Em uma arquitetura cliente/
servidor, os correntistas teriam que instalar o software em seus com-
putadores pessoais. A instalação deste software pode trazer alguns
inconvenientes como:
DD Processamento do computador do cliente: alguns clientes

podem ter computadores que não possuam poder de pro-
cessamento suficiente para o software;
DD Distribuição do software: toda vez que houvesse alguma

alteração no software, o cliente teria que fazer a atualização
em seu computador;
DD Compatibilidade: o software teria que ser compatível com

os diversos sistemas operacionais existentes, como Win-
dows, Linux, entre outros.
41
Tema 1
A solução para resolver estas questões foi criar uma arquitetura

com mais uma camada, localizada entre o cliente e o servidor, cha-
mada de Servidor de Aplicação, para assumir a responsabilidade de
implementar partes das funções antes realizadas pelo cliente. Esta ca-
mada irá implementar as regras de negócio, a lógica de comunicação
com o SGBD e também será responsável por gerar a interface que será
exibida para o cliente. A figura 08 ilustra esta arquitetura.
Arquitetura três camadas.
Os clientes desta arquitetura são os browsers, como Internet

Explorer e Firefox, que têm a responsabilidade de exibir as informa-
ções passadas pelo servidor de aplicação e enviar informações para
42
Banco de Dados I
ele. Neste caso podemos comparar o funcionamento dos browsers

aos antigos terminais “burros”. Esta arquitetura oferece uma série de
vantagens que resolvem os problemas que citamos:
DD Processamento do computador: o computador do usuário

deverá apenas exibir o conteúdo gerado pelo servidor de
aplicação e enviar informações. Não há necessidade de pro-
cessamento adicional (pois grande parte do trabalho será
feito pelo Servidor de Aplicação), desta forma a exigência
por processamento e armazenamento é mínima;
DD Distribuição do software: como não há instalação do sof-

tware cliente, a atualização do servidor de aplicação auto-
maticamente terá efeito quando os usuários acessarem o
sistema pela internet;
DD Compatibilidade: como todos os browsers “falam” a mes-

ma linguagem, o sistema operacional utilizado não tem im-
portância uma vez que a interação do sistema é diretamente
com o browser.
Podemos considerar que a arquitetura de três camadas é a

mais utilizada hoje pela necessidade de aplicações para internet
como, por exemplo, o Internet Banking, item obrigatórios para os
grandes bancos.
43
Tema 1
D ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de

O capítulo 1 deste livro possui uma seção falando sobre as pessoas

que trabalham com banco de dados (seção 1.4). Para complementar
os conhecimentos sobre os diversos tipos de usuários do sistema de
banco de dados, faça uma leitura desta seção comparando com o que
já discutimos neste conteúdo.

A seção 2.10 deste livro o autor aborda a arquitetura cliente/servi-

dor e cita as aplicações criadas para esta arquitetura. Faça a leitura
desta seção para enriquecer seu conhecimento sobre este tipo de
arquitetura.
PARA REFLETIR
Durante todo este conteúdo não citamos e momento algum qualquer
SGBDs. Junto com seus colegas, pesquise e identifique pelo menos
três SGBDs existentes no mercado destacando os líderes de mercado
e empresas que fazem uso destes SGBDs.
44
Banco de Dados I
1.4
PRINCIPAIS COMPONENTES DE UM SGBD
Neste conteúdo iremos tratar dos principais componentes de

um SGBD que resolvem os problemas apresentados no conteúdo 1.1
e garantem a execução das funções básicas de um SGBD citadas no
conteúdo 1.2.
É importante ressaltar que os componentes dos SGBDs não se

limitam aos que iremos falar neste conteúdo, existem outros compo-
nentes, que também chamamos de módulos, que agem no SGBD com
o objetivo de tornar cada vez mais eficiente a gerência dos dados. Os
módulos que iremos tratar neste conteúdo são: Modelo de Dados, Lin-
guagens de Manipulação e Definição de Dados e Processamento de
Transações.
Modelo de Dados
No conteúdo 1.2 falamos sobre a arquitetura três - camadas e
vimos que nesta arquitetura temos um nível que oferece uma visão
abstraída dos dados armazenados no nível físico (nível conceitual).
Esta visão oferece uma representação mais simples dos dados arma-
zenados, garantindo o tratamento eficiente das informações do banco
de dados. Chamamos esta representação de Modelo de Dados.
Fazendo uma definição mais formal, Modelo de Dados é um

conjunto de conceitos que são utilizados para descrever a estrutura
de um banco de dados escondendo detalhes da forma como é feito o
armazenamento dos dados (ELMASRI; NAVATHE, 2005). Os modelos
de dados estão divididos em duas categorias:
45
Tema 1
Modelo de Dados Conceitual: faz a representação da estrutura

de um banco de dados, utilizando conceitos mais flexíveis e com uma
linguagem mais próxima ao do usuário final. O objetivo é definir uma
estrutura de banco de dados para termos uma percepção do mundo
real (SILBERSHATZ; KORTH; SUDARSHAN, 1999) sem regras rígidas
de implementação e independente de tecnologia. Dentro desta cate-
goria, podemos destacar o Modelo Entidade-Relacionamento (E-R)
e Orientado a Objeto (OO). Devido a grande utilização do Modelo E-R
vamos estudá-lo com mais detalhes no tema 2.
Podemos considerar o modelo conceitual, como a primeira pro-

posta de representação do mundo real e como o início do trabalho de
definição da estrutura da base de dados que será utilizada na apli-
cação, a qual será concluída com a implementação do modelo repre-
sentativo que veremos mais adiante. Na definição do modelo concei-
tual não existe preocupação com o SGBD que será utilizado ou com
os recursos tecnológicos necessários, o foco do modelo conceitual é
propor uma estrutura de banco de dados que represente da melhor
forma o mundo real.
Modelo de Dados Representacional: também conhecido como

modelo de dados lógico ou de implementação (ELMASRI; NAVATHE,
2005), representa uma estrutura de banco de dados que será imple-
mentado no SGBD. Este modelo ainda oculta detalhes do armazena-
mento físico dos dados, mas já é aceito por um SGBD no seu nível
conceitual considerando a arquitetura três-camadas. Em comparação
com o modelo conceitual, o modelo representacional já possui concei-
tos mais rígidos e regras para implementação no SGBD. Podemos di-
zer que o modelo representacional possui uma linguagem mais afas-
tada do usuário final, mesmo que ainda seja um modelo que oferece
um bom nível de abstração. Da mesma forma que o modelo conceitual,
o modelo representacional possui várias propostas, entre elas estão o
modelo relacional, de rede e hierárquico. Entre estes três modelos
destacamos o relacional, por ser mais utilizado nos SGBDs atuais. Va-
46
Banco de Dados I
mos estudar mais sobre o modelo relacional no tema 2. Por enquanto,

podemos adiantar que o modelo relacional utiliza um conjunto de ta-
belas para representar os dados de um banco de dados. Por exemplo,
se quisermos armazenar as informações de todos os alunos de uma
universidade, poderíamos representá-los como uma tabela denomi-
nada ALUNOS, onde cada linha representa um aluno da universidade,
conforme podemos ver na tabela 01.
Tabela de Alunos
ALUNOS
Matricula Nome Endereço Cidade Estado

1010 Augusto Rua A Aracaju SE
2020 José Rua D Aracaju SE
3030 João Rua E Propriá SE
Linguagem de Manipulação de Definição de Dados

Após a definição do modelo conceitual e consequente definição
do modelo lógico (incluindo escolha do SGBD), é hora de criar o mode-
lo no SGBD e disponibilizá-lo para aplicação. O modelo lógico é defi-
nido no nível conceitual (na arquitetura três-camadas) e sua criação é
feita através de uma linguagem chamada de linguagem de definição
de dados (DDL – Data Definition Language). Através desta lingua-
gem podemos “conversar” com o SGBD e informá-lo sobre a estrutura
do modelo de dados. Geralmente esta linguagem é utilizada por DBAs
e Projetistas de Banco de Dados, não sendo necessário seu conheci-
mento pelos programadores.
Com o modelo de dados criado no SGBD, podemos iniciar a ma-

nipulação de dados, que significa recuperar, inserir, alterar e excluir
47
Tema 1
dados. Para isso, o SGBD também deve disponibilizar uma linguagem

para realizar tais operações. Esta linguagem é chamada de linguagem
de manipulação de dados (DML – Data Manipulation Language) e
deve ser bem conhecida por todos os profissionais envolvidos no de-
senvolvimento da aplicação, desde o programador até o DBA.
Desenvolver um programa que trabalhe com um SGBD, signi-

fica embutir em uma linguagem tradicional, chamada de hospedei-
ra (ELMASRI; NAVATHE, 2005), como, Java, C#, C++, entre outras,
os comandos DML que realizem operações no banco de dados. Des-
ta forma, quando um usuário final clica em um botão na interface da
aplicação, uma operação DML é enviada para o SGBD, o qual analisa,
processa e retorna uma resposta à requisição DML, que podem ser um
conjunto de dados ou uma resposta do sucesso de uma determinada
operação de manutenção de dados.
Um exemplo de uma linguagem DML é a SQL, a qual estudare-

mos com detalhes nos temas 3 e 4.
Gerenciamento de Transação
Durante a utilização de um SGBD são processadas diversas
transações. Uma transação é solicitada pelo usuário final e representa
um conjunto de operações de manipulação de dados que serão exe-
cutadas no SGBD. Estas operações de manipulação de dados, quan-
do executadas isoladamente, não possuem significado, mas quando
combinada com outras operações, formam uma transação do ponto
de vista do usuário final. Vamos utilizar novamente o exemplo da
transferência entre contas correntes para explicar melhor o conceito
de transação. É responsabilidade do programador escrever o código
para realizar a transação, que ficaria, de uma forma simplificada escri-
ta, em portugol, desta forma:
48
Banco de Dados I
01 Transação Transferência de Contas
02 Leia(ContaOrigem, ContaDestino)
03 Leia(valor)
04 Saldo <- ObterSaldoConta( conta )
05 Se valor > saldo então
06 Escreva ‘Não existe saldo suficiente’
07 Senão
08 Início
09 DebitarSaldo(ContaOrigem,valor)
10 CreditarSaldo(ContaDestino,valor)
11 Fim
12 Transação Fim
A tabela 02 descreve a responsabilidade das operações de ban-

co de dados ObterSaldoConta, DecrementarSaldo e IncrementarSaldo.
49
Tema 1
Operações de manipulação de dados a transação de transferên-

cia de conta
ObterSaldoConta(conta) Obtém o saldo atual da conta informada.

DecrementarSaldo Decrementa o saldo atual da conta informada
(conta, valor) com base no valor passado. Se o saldo atual for
R$ 1.000,00 e o valor informado for R$ 50,00 o
saldo passará a ter o valor de R$ 950,00.
IncrementarSaldo Incrementa o saldo atual da conta informada
(conta,valor) com base no valor passado. Se o saldo atual for
R$ 1.000,00 e o valor informado for R$ 50,00 o
saldo passará a ter o valor de R$ 1.050,00.
Analisando o algoritmo que implementa a transferência de

contas, podemos pensar que não teremos problemas durante a sua
execução que deixe os dados inconsistentes. Realmente, observando
apenas a lógica, não teremos problemas, porém, existem fatores ex-
ternos à lógica que podem acarretar na inconsistência dos dados.
Agora imagine que durante a execução da transação uma falha

ocorresse na linha 10. Neste momento, o débito da conta de origem
já ocorreu, mas o crédito na conta de desconto não. Nesta condição
temos uma inconsistência de dados, pois a conta de origem não rece-
beu o devido crédito e a conta de destino recebeu o débito. E agora? É
responsabilidade do SGBD garantir o que chamamos de atomicidade,
ou seja, ou faz tudo ou não faz nada (SILBERSHATZ; KORTH; SUDAR-
SHAN, 1999). Uma transação não pode ser executada parcialmente,
neste caso o SGBD deve detectar a falha e desfazer a operação de dé-
bito realizada de forma a tornar os dados consistentes.
Apenas a garantia da atomicidade não oferece por completo a

consistência dos dados ao final da transação. O SGBD deve garantir,
também, que não haja violação das restrições definidas no modelo de
dados, para que o banco de dados saia de um estado consistente no
50
Banco de Dados I
início da transação para outro estado também consistente ao final da

transação (SILBERSHATZ; KORTH; SUDARSHAN, 1999).
Vimos que atomicidade e consistência são propriedades que

devem ser asseguradas pelo SGBD, mais especificamente pelo mó-
dulo de gerenciamento de transação. Além destas propriedades, o
SGBD deve assegurar a durabilidade dos dados manipulados durante
a transação, ou seja, garantir que as alterações realizadas permane-
çam no banco de dados ao final da transação mesmo na ocorrência de
uma falha (SILBERSHATZ; KORTH; SUDARSHAN, 1999) após o final
da transação.
Para complementar as funções do módulo de gerenciamento de

transação, ainda precisamos considerar o fato das transações esta-
rem sendo executadas em um ambiente multiusuário. Para podermos
explicar o papel do gerenciador de transação neste cenário, vamos
entender como o SGBD gerencia as diversas transações solicitadas
pelos usuários.
Para atender as solicitações de dezenas, centenas e às vezes

milhares de usuários, o SGBD deve implementar o conceito de multi-
programação. Este conceito consiste em executar diversas transações
originárias de usuários diferentes ao mesmo tempo. Na verdade só
seria possível executar mais de uma transação ao mesmo tempo se o
SGBD tivesse uma CPU trabalhando para cada transação.
Como sabemos que isto não é possível, o SGBD utiliza a mesma

estratégia dos sistemas operacionais-execução intercalada de transa-
ções (ELMASRI; NAVATHE, 2005). Esta estratégia consiste em exe-
cutar algumas operações de uma transação, suspendê-la, executar
alguns comandos de outra transação, suspendê-la, e retomar a pri-
meira transação do ponto em que foi suspensa. Esta alocação é feita
diversas vezes e com várias transações, como a alocação é realizada
de forma bem rápida, na maioria das vezes, é imperceptível ao usu-
51
Tema 1
ário final. A figura 09, explica de forma gráfica a execução de duas

transações no SGBD. Note que as transações A e B são intercaladas
permitindo a execução simultânea das transações.
Execução intercalada de transações
Quando temos mais de uma transação sendo

executada ao mesmo tempo no SGBD, clas-
sificamo-las como Transações Concorren-
tes.
52
Banco de Dados I
Esta estratégia é realizada para reduzir o tempo de resposta

das transações. Tempo de resposta é o intervalo entre a solicitação
do usuário para execução de uma transação e a sua finalização. Se
não houvesse a implementação desta estratégia, as transações se-
riam enfileiradas e atendidas uma depois das outras. Imagine agora
quanto tempo o último usuário esperaria para executar sua transação.
Ao intercalar a execução das transações o SGBD inicia a execução de
transações sem esperar pelo término da anterior reduzindo o tempo
de médio de resposta.
Apesar de ajudar na redução do tempo médio de resposta, a

execução concorrente gera diversas complicações em relação à con-
sistência dos dados (SILBERSHATZ; KORTH; SUDARSHAN, 1999).
Mesmo acarretando em problemas de consistências, a execução in-
tercalada de transação é fundamental para otimizar o desempenho do
SGBD. Diante desta necessidade, os SGBDs implementam o módulo
de controle de concorrência, o qual é responsável por garantir a con-
sistência dos dados mesmo na execução concorrente.
Para entendermos melhor a importância do módulo de controle

de concorrência, vamos imaginar uma execução concorrente da tran-
sação de transferência de conta sendo iniciada por dois usuários ao
mesmo tempo e transferindo valores para as mesmas contas, confor-
me tabela 03.
53
Tema 1
Execução concorrente da transação de transferência entre

contas
T Transação Usuário 1 Transação Usuário 2
1 Leia(ContaA,ContaB)
2 Leia(valor)
3 Saldo<-ObterSaldoConta(contaA)
5 Leia(valor)
Escreva‘Não existe
saldo suficiente’
Senão
Inicio
DebitarSaldo(ContaA,valor)
CreditarSaldo(ContaB,valor)
Fim
saldo suficiente’
Senão
Inicio
Fim
54
Banco de Dados I
Neste exemplo existe uma intercalação da transação de trans-

ferência entre contas. Observem que as transações são executadas
por usuários diferentes, mas que manipulam o saldo da conta A e de
conta B. Vamos imaginar que a conta A possui um saldo inicial de R$
100,00 e a conta B um saldo de R$ 100,00 e que o usuário 1 está so-
licitando uma transferência de R$ 100,00 e o usuário 2 de R$ 50,00.
Verificando o saldo da conta A, sabemos que não é possível realizar
as duas transações, pois é necessário R$ 150,00 sendo que a conta A
só dispõe de R$ 100,00. Apesar de sabermos que as duas transações
não poderiam ser realizadas, a intercalação proposta no nosso exem-
plo permitirá as transações e deixará o saldo da conta A inconsistente
em relação à realidade. Esta inconsistência acontece, pois as leituras
no banco de dados do saldo da conta A pelo usuário 1 (tempo 3) e pelo
usuário 2 (tempo 6) acontecem antes das operações de débito ou cré-
dito. Desta forma, tanto o usuário 1 como o usuário 2 obtém do banco
de dados o saldo de R$ 100,00, permitindo que as transações sejam
realizadas, pois em ambos os casos o valor solicitado é suficiente para
o saldo. No final das duas transações teremos dois saques da conta A
acumulando R$ 150,00, sendo que o saldo inicial da conta era de R$
100,00.
É função do SGBD, mais especificamente do seu módulo de

controle de concorrência, não permitir que este tipo de inconsistência
ocorra. Ao garantir este tipo de inconsistência o SGBD está preservan-
do a propriedade de isolamento da transação. Segundo (ELMARSI,
2005) isolamento consiste na capacidade do SGBD em garantir que
durante a execução de uma transação, esta não sofrerá interferências
de outras que estão sendo executadas simultaneamente. Considera-
mos interferência qualquer manipulação em dados que estejam sendo
utilizados pela transação. Esta propriedade seria facilmente obtida se
as transações fossem executadas sequencialmente ou de forma se-
rializada, como demonstrado na tabela 04.
55
Tema 1
Execução sequencial da transação de transferência entre contas
T Transação Usuário 1 Transação Usuário 2
2 Leia(valor)
saldo suficiente’
Senão
Inicio
Fim
6 Leia(valor)
saldo suficiente’
Senão
Inicio
Fim
Sabemos que a execução serializada, apesar de ser uma estra-

tégia que garante a consistência dos dados, não é eficiente, pois eleva
o tempo de resposta das transações.
56
Banco de Dados I
Garantindo o isolamento, o módulo de controle de concorrência

faz com que suas transações sejam executadas como se estivessem
serializadas (uma após a outra), ou seja, elas “pensam” que estão so-
zinhas na execução, mas na verdade estão sendo intercaladas com
outras.
Podemos resumir a responsabilidade do módulo de gerência de

transações em quatro palavras que falamos bastante nestes últimos
parágrafos, são elas: Atomicidade, Consistência, Isolamento e Du-
rabilidade. Elas formam a sigla bastante conhecida ACID.
Uma transação para ser executada ela passa por várias etapas, desde
a inicialização até a finalização com sucesso ou não. No AVA faça a
leitura do material “Estados de uma transação” para completar seus
conhecimentos sobre o módulo de gerenciamento de transações.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de

Neste conteúdo falamos várias vezes sobre a responsabilidade do

SGBD em realizar a gerência das transações concorrentes de forma
a garantir a propriedade de isolamento. Durante o desenvolvimento
de um software geralmente não nos preocupamos com isso (uma vez
que o SGBD nos ajuda), porém a tarefa de controlar a concorrência é
bastante complexa. No capítulo 18 deste livro você poderá se aprofun-
dar nas técnicas utilizadas pelo SGBD para implementar o controle de
concorrência.
57
Tema 1
PARA REFLETIR
Vimos que a execução intercalada das transações reduz o tempo mé-
dio de resposta em um ambiente com vários usuários conectados.
Além deste benefício, esta estratégia otimiza o uso da CPU durante a
execução das diversas transações. Junto com seus colegas, pesquise
como a execução intercalada das transações garante uma utilização
mais eficiente da CPU.
RESUMO
Neste tema fizemos uma introdução sobre banco de dados demons-
trando alguns conceitos e como podemos utilizá-lo em ambientes
computacionais. Também vimos o conceito de Sistemas Gerenciado-
res de Banco de Dados (SGDB) e a sua importância para os softwares
que necessitam trabalhar com informações armazenadas nos bancos
de dados. No final conhecemos os profissionais que fazem uso direta
ou indiretamente dos SGBDs e os diversos tipos de softwares que os
utilizam, verificando as diversas arquiteturas que organizam a comu-
nicação entre os softwares e os SGBDs.
Nos próximos temas vamos nos aprofundar nos principais elemen-

tos que compõe um SGBD, o Modelo de Dados e a Linguagem de
Acessos a Dados. Conhecendo bem estes dois elementos poderemos
construir softwares que interagem com os SGBDs de maneira simples
e eficiente.
Anotações

01 Banco de Dados I

Enviado por

Dados do documento

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

01 Banco de Dados I

Enviado por

Direitos autorais:

Formatos disponíveis

Parte 1

Depois da leitura deste tema verificaremos que

O conceito de banco de dados não está restrito a área da tec-

Os bancos de dados podem ser trabalhados de forma manual

O banco de dados computadorizado armazena dados digitais,

que também possuem a responsabilidade de localizar a informação

DD Economia de espaço físico: poderemos substituir uma sala

DD Organização: não serão necessárias várias pessoas para

DD Rapidez na localização da informação: para encontrar uma

DD Redução na quantidade de papel: o armazenamento digital

O objetivo deste livro é estudar os bancos de dados computa-

Sistema Gerenciador de Banco de Dados

Um banco de dados consiste basicamente em um conjunto de

Desta forma, durante o desenvolvimento de um software, o pro-

Interação software com arquivos do banco de dados – Sem SGBD.

Durante a implementação da lógica de manipulação dos arqui-

D Segurança: geralmente um banco de dados é acessado por

D Integridade: falaremos muito nesta palavra. O seu propó-

D Atomicidade: geralmente uma funcionalidade do software

Verificar se saldo da conta A é suficiente;

Debitar R$ 100,00 da conta A;

Creditar R$ 100, 00 da conta B.

Se tudo corresse bem, teríamos, ao final da operação, o crédito e

Transação: No contexto de banco de dados,

D Concorrência: como o banco de dados pode ser acessado

Além destes fatores, o programador terá que solucionar mais

to à complexidade de trabalhar com os arquivos. O programador deve

Como um banco de dados é composto por vários arquivos, o

Diante de todos estes aspectos e problemas, os programadores

Os Sistemas Gerenciadores de Banco de Dados (SGBD) surgi-

O SGBD é uma parte do que iremos chamar neste livro de Siste-

O SGBD está localizado entre a aplicação cliente e o banco de

estar entre a aplicação cliente e o banco de dados, o SGBD simplifica a

Arquitetura básica de um sistema de banco de dados.

Na seção 1.2 faremos um estudo mais detalhado sobre SGBD,

Os conceitos e elementos do sistema de banco de dados são abor-

D SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S.

No primeiro capítulo deste livro você terá maiores detalhes sobre os

Existem várias definições para um SGBD. Elmasri e Navathe

Como já citado no conteúdo 1.1, o SGBD tem a função de facili-

O SGBD não tem uma finalidade específica, é um software de

Se quiséssemos resumir as funções disponibilizas por um SGDB po-

D Definição: oferecer recursos que facilitam a definição do

D Construção: permitir o armazenamento do banco de dados

DD Manipulação: disponibilizar recursos que facilitem e otimi-

DD Compartilhamento: permitir que o banco de dados possa

DD Proteção: proteger o banco de dados de possíveis falhas e

DD Manutenção: manter os dados por um longo período de tempo.

No transcorrer deste tema veremos os elementos do SGBD que

Denominada Arquitetura de Três-Esquemas, ela está baseada

Agora vamos entender melhor estes níveis e como eles garan-

DD Nível Físico: também chamado de interno, descreve os

DD Nível Conceitual: geralmente acessado pelos programa-

Mapeamento do nível interno para o modelo de dados relacional.

DD Nível Externo: na maioria das vezes os usuários não neces-

plifica a manipulação das informações no banco de dados

A arquitetura três-esquemas é ilustrada pela figura 04.

Visão Geral de uma Arquitetura Três-Esquemas.

Uma característica fundamental dos SGBD é que, além de arma-

O catálogo é utilizado para o SGBD realizar o mapeamento entre

Todo este trabalho é transparente ao usuário, é o que chama-

tam-se mais a vontade para trabalhar. Esta abstração tem um grande

Você agora deve estar pensando o seguinte: “Tenho uma visão

Em determinadas situações, é necessário realizar alterações no