Livro Unip Administração de Banco de Dados

Prévia do material em texto

Administração de 
Banco de Dados
Professora conteudista: Cida Atum
Administração de Banco de Dados
Unidade I
1 INTRODUÇÃO A BANCO DE DADOS ............................................................................................................1
1.1 Histórico ......................................................................................................................................................1
1.2 Definições ...................................................................................................................................................2
1.3 Importância dos sistemas de bancos de dados nas organizações ......................................3
1.4 Linguagens de banco de dados .........................................................................................................4
1.5 Níveis da arquitetura de banco de dados ......................................................................................6
2 SISTEMAS GERENCIADORES DE BANCO DE DADOS - SGBD ............................................................7
2.1 Definição .....................................................................................................................................................7
2.2 Características do SGBD .......................................................................................................................9
2.3 Projeto de banco de dados ..................................................................................................................9
Unidade II
3 MODELAGEM DE DADOS ...............................................................................................................................11
3.1 Tipos de modelos de dados ...............................................................................................................11
3.1.1 Modelo conceitual ...................................................................................................................................11
3.1.2 Modelo lógico ...........................................................................................................................................11
3.1.3 Modelo físico ............................................................................................................................................ 12
3.2 Modelo Entidade-Relacionamento (MER) ................................................................................. 12
3.2.1 Atributos ..................................................................................................................................................... 14
3.2.2 Restrições ................................................................................................................................................... 14
3.2.3 Entidades fortes e entidades fracas ................................................................................................ 16
3.3 Dicionário de dados ............................................................................................................................. 18
3.4 Ferramentas CASE ................................................................................................................................ 19
3.4.1 Definição .................................................................................................................................................... 19
3.4.2 A ferramenta CASE ErWin ................................................................................................................... 20
Unidade III
4 ADMINISTRAÇÃO DE SGBDs ....................................................................................................................... 24
4.1 Segurança e administração - controle de acesso ................................................................... 26
4.2 Recuperação (recovery) ..................................................................................................................... 28
4.2.1 Recuperação de sistema ...................................................................................................................... 29
4.2.2 Recuperação da mídia .......................................................................................................................... 30
4.3 Replicação de dados ........................................................................................................................... 31
4.4 Formas de melhoria de desempenho ........................................................................................... 33
4.4.1 Simulação de desempenho ................................................................................................................. 33
Sumário
Unidade IV
5 DEFINIR A MELHOR SOLUÇÃO DE BANCO DE DADOS PARA AS NECESSIDADES
DA EMPRESA ......................................................................................................................................................... 35
5.1 O uso das tecnologias ......................................................................................................................... 35
5.1.1 O software livre ....................................................................................................................................... 35
5.1.2 Ferramentas de SGBD ........................................................................................................................... 37
5.2 Requisitos de software – arquitetura cliente/servidor .......................................................... 40
ADMINISTRAÇÃO DE BANCO DE DADOS
1 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
5
10
15
20
1 INTRODUÇÃO A BANCO DE DADOS
1.1 Histórico
O banco de dados relacional surgiu na empresa IBM entre 
as décadas de 1960 e 1970, ao desenvolver funções através de 
pesquisas de automação de escritório. Tal necessidade deve-se 
ao fato de que as empresas constatavam o baixo custo da 
informatização em tarefas que exigiam processos repetitivos. 
Iniciou-se uma época muito valiosa de pesquisas em linguagem 
de programação industrial com altos investimentos na área.
As pesquisas desenvolvidas nesta época trouxeram os 
primeiros estudos sobre modelos de banco de dados de rede 
hierárquicos, além de outras tecnologias empregadas até hoje.
Ted Codd era um destes pesquisadores, e, em 1970, escreveu 
um artigo técnico sobre Banco de Dados Relacionais, no qual 
estabelecia o conceito primordial da linguagem: o armazenamento 
das informações em tabelas onde o usuário poderia acessá-las 
através de comando em inglês. A complexidade do artigo levou 
a IBM a organizar um centro de pesquisa que ficou conhecido 
como System R, tendo como principal intuito desenvolver um 
produto cujo sistema fosse um banco de dados relacional.
O System R teve muitas versões que foram sendo utilizadas 
por várias organizações de peso nos Estados Unidos, até que 
a evolução do sistema eventualmente tornou-se DB2, e a 
linguagem desenvolvida para ser utilizada junto ao sistema 
foi a SQL (Structured Query Language - Linguagem de 
Consulta Estruturada), considerada pela ISO (International 
Unidade I
Unidade I
2R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Organization for Standardization - Organização Internacional 
de Padronização) linguagem padrão dos sistemas de banco de 
dados relacionais.
Apesar do pioneirismo conceitual da IBM, foi mesmo a 
Honeywell Information Systems Inc a primeira empresa a 
produzir comercialmente o sistema de banco de dados em 1976. 
A Honeywell implementou o sistema criado pela IBM e este foi 
completamente remodelado.
Na década de 80 os softwares de banco de dados 
relacionais foram sendo evoluídos e os usuários começaram 
um processo de feedback do sistema, devido principalmenteao vertiginoso aumento de sistemas distribuídos e aos 
computadores-pessoas.
Atualmente a capacidade de armazenamento de dados 
ultrapassa centenas de Terabytes, o que levou consequentemente 
ao aumento de tamanho destes sistemas. Um dos projetos mais 
ambiciosos trata-se do desenvolvimento de um banco de dados 
distribuído que possui uma capacidade de armazenamento em 
torno de Hexabytes (1 Hexabyte = 1,000 Petabytes = 1 * 10^18 
Bytes), este projeto está em fase de andamento pela CERN 
(European Organization for Nuclear Research - Organização 
Européia para a Investigação Nuclear).
O desenvolvimento da linguagem padrão SQL é financiado 
atualmente pela ANSI (American National Standards Institute 
- Instituto Nacional Americano para Padrões) e pela ISO, que 
formam um grupo de pesquisas para a contínua evolução da 
linguagem.
1.2 Definições
Banco de dados é uma coleção de dados inter-relacionados 
cuja representação refere-se a informações específicas, como por 
exemplo, acervos de bibliotecas, lista de clientes e fornecedores, 
controle de RH de uma empresa, etc.
5
10
15
20
25
30
ADMINISTRAÇÃO DE BANCO DE DADOS
3 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Banco de dados relacional é baseado no modelo relacional 
e usa um conjunto de tabelas para representar os dados e as 
relações entre si, a maioria utiliza a linguagem SQL.
1.3 Importância dos sistemas de bancos de 
dados nas organizações
A importância dos sistemas de bancos de dados nas 
organizações é vista pela crescente valorização dos bancos de 
dados e dos SGBDs, o que gera consequentes investimentos 
em técnicas de gerenciamento, monitoramento, backup 
e restauração de dados e em todo o processo que envolve a 
importância financeira de manter a integridade dos bancos de 
dados.
Um problema muito real refere-se ao gerenciamento de 
todas as contas bancárias em sistemas de arquivos permanentes 
de um determinado banco. Este sistema possui uma série de 
programas aplicativos necessários para a manipulação por parte 
dos usuários, que permitem:
• débito e crédito em outra conta;
• um programa para adicionar uma nova conta;
• fazer pagamentos e depósitos;
• calcular aplicações;
• inserir novas alíquotas.
Esses aplicativos só foram desenvolvidos porque surgiram 
problemas e necessidades da organização bancária, e isso significa 
um processo contínuo, pois as aplicações são desenvolvidas 
conforme vão surgindo as necessidades. Em resumo, os arquivos 
e os programas são desenvolvidos e acrescidos ao sistema 
sempre que for preciso.
5
10
15
20
25
Unidade I
4R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Este sistema de processamento de arquivos tem deixado 
de existir gradualmente, pois apresenta uma infinidade de 
desvantagens, como define Silberschatz (et. tal,1999):
• difícil acesso: filtrar uma informação torna-se uma 
tarefa árdua, já que se pode fazer isso manualmente ou se 
pode gerar um programa para cada filtro;
• isolamento: a informação de formatos diferentes contida 
em arquivos separados torna difícil desenvolver novos 
programas aplicativos de recuperação de dados;
• redundância e inconsistência: diversos programadores 
e diversas linguagens produzem vários tipos de formatos, 
podendo ser geradas por exemplo, informações em 
duplicidade, em tabelas diferentes. Inconsistência de 
dados é gerada pela manutenção de cópias que podem 
estar com valores diferentes;
• problemas de segurança: um banco de dados deve 
manter controles de acessos, dependendo da informação. 
Se os aplicativos forem adicionados regularmente, este 
processo de segurança fica restrito;
• problemas de integridade: às vezes os valores dos 
dados precisam satisfazer algumas restrições, como 
o saldo nunca estar abaixo de “X” reais, por exemplo. 
Quando novas restrições forem necessárias, torna-se-á 
difícil alterar estes programas.
Estes são alguns dos motivos pelos quais se faz necessária 
uma séria abordagem da aplicação de gerenciamento de sistemas 
de banco de dados em uma organização.
1.4 Linguagens de banco de dados
Um sistema de banco de dados fornece uma linguagem 
de definição de dados para especificar o esquema do mesmo 
e, uma linguagem de manipulação de dados para expressar as 
5
10
15
20
25
30
ADMINISTRAÇÃO DE BANCO DE DADOS
5 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
consultas e a atualização de dados. Na prática, as linguagens 
de definição de dados e de manipulação de dados são duas 
linguagens separadas, simplesmente formam partes de uma 
única linguagem de banco de dados, como a amplamente usada 
linguagem SQL (DATE, 2003).
Linguagem de Definição de Dados - DDL
Os procedimentos de acesso a um sistema de banco de 
dados e sua estrutura de armazenamento são definidos por um 
conjunto de comandos básicos chamados DDL (Data Definition 
Language - Linguagem de Definição de Dados), que permite ao 
usuário definir tabelas novas e seus elementos. Os comandos 
DDL são:
• CREATE: cria uma tabela;
• DROP: exclui uma tabela;
• ALTER: altera a estrutura da tabela.
Linguagem de Manipulação de Dados - DML
A linguagem DML (Data Manipulation Language, - 
Linguagem de Manipulação de Dados) permite o acesso aos 
dados e/ou manipulá-los. Existem basicamente 4 comandos 
DML:
• SELECT: seleciona dados especificando uma query 
(comando que executa uma busca);
• INSERT: insere dados a uma tabela existente;
• UPDATE: altera os valores de dados em tabela;
• DELETE: remove dados de uma tabela.
A seguir podemos visualizar a completa arquitetura de um 
sistema de banco de dados (Fig. 1.1):
5
10
15
20
25
Unidade I
6R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Sistema de 
banco de 
dados
Software
SGBD
Programas aplicativos / 
Consultas
Processador / Otimizador 
de Consultas
Software para acessar 
os dados
Definição dos dados 
armazenados
(metadados)
Dados armazenados
(metadados)
Usuários e 
Programadores
Fig. 1.1 - Diagrama da arquitetura do sistema de banco de dados
1.5 Níveis da arquitetura de banco de dados
De modo geral, como nos mostra DATE (2003:29), a 
arquitetura se divide em três níveis (Fig. 1.2), a saber:
- O nível interno (também conhecido como nível de 
armazenamento) é o mais próximo do meio de armazenamento 
físico, ou seja, é aquele que se ocupa do modo como os dados 
são fisicamente armazenados dentro do sistema.
- O nível externo (também conhecido como nível lógico 
do usuário) é o mais próximo dos usuários, ou seja, é aquele 
que se ocupa do modo como os dados são vistos por usuários 
individuais.
- O nível conceitual (também conhecido como nível 
lógico de comunidade, ou às vezes apenas nível lógico, sem 
qualificação), é um nível “indireto” entre os outros dois.
5
10
ADMINISTRAÇÃO DE BANCO DE DADOS
7 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Nível externo
(visões de usuários 
individuais)
Nível conceitual
(visão de comunidade 
de usuários)
Nível interno
(visão do meio de 
armazenamento)
Fig. 1.2 – Os três níveis da arquitetura.
Observe que o nível externo se preocupa com as percepções 
dos usuários individuais, enquanto o nível conceitual está 
preocupado com uma percepção da comunidade de usuários. 
A maior parte dos usuários não estará interessada no banco de 
dados inteiro, mas somente em alguma parte restrita dele; assim, 
haverá muitas “visões externas” distintas, cada qual consistindo 
em uma representação mais ou menos abstrata de alguma parte 
do banco de dados completo,e haverá exatamente uma “visão 
conceitual”, consistindo em uma representação igualmente 
abstrata do banco de dados em sua totalidade. Do mesmo modo, 
haverá exatamente uma “visão interna”, representando o modo 
como o banco de dados está armazenado internamente.
Observe que os níveis externo e conceitual são níveis de 
modelo, enquanto o nível interno é um nível de implementação; 
em outras palavras, os níveis externo e conceitual são definidos 
em termos de construções voltadas para o usuário, como registros 
e campos, enquanto o nível interno é definido em termos de 
construções voltadas para a máquina, como bits e bytes.
2 SISTEMAS GERENCIADORES DE BANCO DE 
DADOS - SGBD
2.1 Definição
Sistema Gerenciadores de Banco de Dados (SGBD) é 
um programa com recursos específicos, que tem o objetivo de 
manipular as informações contidas nos bancos de dados. Como 
5
10
15
20
Unidade I
8R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
exemplo podemos citar o Ingres, o Oracle, o Access, o MySQL e 
o DBase.
Um Sistema Gerenciador de Banco de Dados, 
normalmente referido apenas por “banco de dados”, refere-
se à administração gerencial de um conjunto de dados, 
estruturando com eficiência as informações e adequadamente 
às exigências de segurança e armazenamento (MEDEIROS, 
2006).
A função do SGBD é facilitar e simplificar o acesso aos dados 
pelos usuários, gerenciando grupos complexos de informações 
e fornecendo segurança contra os problemas que venham a 
ocorrer no sistema e contra a invasão de acessos restritos.
Os componentes funcionais de um banco de dados incluem:
•-gerenciador de arquivos: gerencia o espaço do 
armazenamento;
• gerenciador do banco de dados: gerencia a interface 
entre os dados e os programas aplicativos;
• processador de consultas: traduz os comandos numa 
linguagem que o gerenciador do banco de dados possa 
interpretar;
• pré-compilador da DML: converte comandos DML para 
gerar o código apropriado;
• compilador da DDL: converte comandos DDL em um 
conjunto de tabelas contendo metadados.
Além desses componentes, outros são relativamente 
importantes no desenvolvimento da fase do projeto físico do 
sistema:
• arquivos de dados: é o armazenamento físico do banco 
de dados;
•-dicionário de dados: é o armazenamento dos 
metadados;
5
10
15
20
25
30
ADMINISTRAÇÃO DE BANCO DE DADOS
9 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
• índices: o acesso ágil aos dados.
2.2 Características do SGBD
Geralmente um Sistema Gerenciador de Banco de Dados 
deve ter as seguintes características:
•-evitar a redundância: deve poder evitar dados 
redundantes, evitando a inconsistência das informações;
• manipulabilidade: deve facilitar o uso do banco de dados 
mesmo aos que não o conhecem tecnicamente.
• independência física: o esquema do modelo lógico deve 
manter-se afastado do nível físico do SGBD para que não 
haja abstrações, simplificando a interação do usuário com 
o sistema;
• independência lógica: o nível físico do SGBD pode ser 
alterado independentemente da utilização do usuário;
•-centralização administrativa: deve permitir o 
gerenciamento dos SGBDs de maneira centralizada;
• rapidez dos acessos: deve permitir o acesso rápido e ágil 
aos dados;
• preservar a integridade: preservar a coerência entre os 
dados;
• compartilhamento: deve permitir o acesso simultâneo ao 
banco de dados;
• segurança dos dados: deve prevenir-se de métodos de 
gerenciamento de acesso.
2.3 Projeto de banco de dados
Segundo Silberschatz (et. tal,1999), um sistema de banco de 
dados é projetado para gerenciar grandes blocos de informações. 
Esses grandes blocos não existem isoladamente. Eles são parte 
da operação de alguma empresa cujo produto final pode ser 
5
10
15
20
25
Unidade I
10R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
informações do banco de dados ou pode ser algum dispositivo 
ou serviço para o qual o banco de dados desempenha apenas 
um papel de apoio.
O projeto de banco de dados envolve principalmente o 
projeto do esquema de banco de dados. A modelagem requer 
atenção especial.
Um modelo de dados serve ao projetista de banco de 
dados uma estrutura conceitual para especificar, de maneira 
sistemática, quais são as necessidades, por exemplo, numa 
instituição financeira, de dados dos usuários do banco de 
dados, e como o banco será estruturado para satisfazer essas 
necessidades. Portanto, a fase inicial do projeto de banco de 
dados é caracterizar completamente as necessidades de dados 
dos usuários de banco de dados potenciais.
O projetista de banco de dados precisa interagir 
extensivamente com especialistas e usuários do domínio para 
realizar essa tarefa. O resultado dessa fase é uma especificação 
das necessidades do usuário.
A seguir, o projetista escolhe um modelo de dados e, 
aplicando os conceitos do modelo escolhido, traduz essas 
necessidades em um esquema conceitual do banco de dados. 
O esquema desenvolvido nessa fase de projeto conceitual 
fornece uma visão geral detalhada da empresa. O projetista 
revisa o esquema para confirmar se todas as necessidades de 
dados estão realmente satisfatórias e se não estão em conflito 
entre si. O projetista também pode examinar o projeto para 
remover quaisquer recursos redundantes. O foco nesse momento 
é descrever os dados e suas relações, e não especificar detalhes 
do armazenamento físico.
Em termos do modelo relacional, o processo do projeto 
conceitual envolve decisões sobre quais atributos queremos 
capturar no banco de dados e como agrupar esses atributos para 
formar as várias tabelas. A maneira mais utilizada para tratar 
esse problema é usar o modelo de entidade/relacionamento.
5
10
15
20
25
30
ADMINISTRAÇÃO DE BANCO DE DADOS
11 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
3 MODELAGEM DE DADOS
Silberschatz nos dá uma definição do que vem a ser 
modelagem de dados (SILBERSCHATZ, et. tal, 1999:5): 
“Apoiando a estrutura de um banco de dados está o 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”. Um modelo de dados oferece uma maneira de 
descrever o projeto de um banco de dados no nível físico e 
lógico.
3.1 Tipos de modelos de dados
3.1.1 Modelo conceitual
O modelo conceitual não considera a estrutura do banco 
de dados para o seu desenvolvimento, mas a forma como as 
estruturas são criadas tendo em vista o armazenamento dos 
dados.
Representado através do diagrama entidade-
relacionamento, traduz naturalmente os fatos, portanto é a 
fase de maior proximidade com o cliente, pois também ocorre o 
levantamento de dados que dá a sustentação da base de todo 
o projeto.
3.1.2 Modelo lógico
O modelo lógico tem como objetivo a implementação de 
recursos que definem padrões e nomenclaturas, e, também, 
como estabelecer chaves primárias e estrangeiras.
5
10
15
20
Unidade II
Unidade II
12R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
A estruturação do modelo lógico se norteia completamente 
no modelo conceitual que foi desenvolvido anteriormente.
É o modelo mais usado, a grande maioria dos sistemas de 
banco de dados atuais se baseia neste modelo.
3.1.3 Modelo físico
A modelagem física do modelo de banco de dados consiste 
em levar em conta o sistema gerenciador de banco de 
dados, além de se nortear pelo modelo lógico quanto ao seu 
desenvolvimento.
3.2 Modelo Entidade-Relacionamento (MER)
O ModeloEntidade-Relacionamento (MER) parte 
da percepção mais próxima da realidade, é representado por 
elementos denominados entidades, e as relações entre 
esses elementos são denominadas relacionamentos.
Sua função é representar a estrutura lógica geral do banco 
de dados e facilitar a implementação do sistema através de um 
esquema envolvendo representações gráficas.
Entidade é o objeto que se distingue por existir 
através de um conjunto específico de atributos, enquanto 
Relacionamento é a associação entre entidades. Tanto 
um conjunto de entidades quanto um conjunto de 
relacionamentos devem pertencer ao mesmo tipo de 
entidades.
A estrutura lógica geral de um banco de dados pode ser 
representada graficamente por um diagrama ER, conforme 
a Fig. 3.1 a seguir, contendo toda a representação gráfica do 
MER:
5
10
15
20
25
ADMINISTRAÇÃO DE BANCO DE DADOS
13 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
E1 R E2
RE1 E21 N
R E
(min, max)
Entidade (forte)
Entidades (fracas)
Relacionamentos
Relacionamentos dependentes
Atributos
Atributo chave
Atributo chave parcial
(Entidades fracas)
Atributo multivalorado
Atributo composto
Atributo derivado
Total participação de E2 em R
Cardinalidade 1:N para E1:E2 em R
Restrição de cardinalidade (min, máx) na 
participação de E em R
Fig. 3.1 - Representação gráfica do MER
Para ilustrar, considere parte de um sistema de banco de 
dados de uma instituição bancária, consistindo em clientes 
e contas que eles possuem. O diagrama ER correspondente é 
mostrado na figura abaixo (Fig. 3.2):
Conta 
Cliente
Possui Pertencenome
nome
rua
cidade número saldo
Conta
Fig. 3.2 - Exemplo de diagrama ER
Unidade II
14R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
3.2.1 Atributos
Formalmente um atributo identifica uma entidade 
constituindo uma parte significativa dos dados armazenados 
no banco de dados. Pode ser caracterizado pelos seguintes 
tipos:
• atributos simples e compostos: a diferença entre 
atributos simples e compostos é que os compostos 
são divididos em subpastas, ou seja, outros atributos, o 
que ajuda a agrupar atributos relacionados e tornar a 
modelagem mais clara. Ex.: um atributo nome poderia ser 
estruturado como um atributo composto consistindo em 
primeiro_nome, sobre_nome e apelido_nome;
• atributos de valor único e multivalorado: de valor 
único são atributos que permitem apenas um valor por 
determinada entidade, ao contrário do multivalorado. 
Ex.: nr_empréstimo significa que para a entidade 
“empréstimo” haverá um único valor. Já nr_fone, 
significa que para a entidade “funcionário” poderá 
haver zero ou vários telefones.
3.2.2 Restrições
No esquema ER existem certas restrições com as quais 
o conteúdo de um banco de dados precisa se conformar. 
Para determinar tais restrições é preciso examinar as 
cardinalidades de mapeamento e as restrições de chave.
As cardinalidades de mapeamento expressam o número 
de entidades ao qual outra entidade pode ser associada por um 
conjunto de relacionamento. São úteis em descrever conjuntos 
de relacionamento binário, embora possam contribuir para a 
descrição dos conjuntos de relacionamento que envolvam mais 
de dois conjuntos de entidades.
5
10
15
20
25
ADMINISTRAÇÃO DE BANCO DE DADOS
15 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Existem três tipos de relacionamento entre entidades que 
indicam a cardinalidade de mapeamento:
• um-para-um: uma entidade A é associada a no máximo 
uma entidade B e vice-versa, e é representado pelo sinal: 
1:1. Ex.: 
Chefia
1
Gerente Seção
1
• um-para-muitos: uma entidade A é associada a qualquer 
número de entidades em B, e é representado pelo sinal: 1:
N. Ex.:
Trabalha
1
Seção Funcionário
N
• muitos-para-muitos: várias entidades A são associadas 
a várias entidades B, e é representado pelo sinal: N:N ou 
N:M. Ex.:
Fornece
N
Fornecedor Produto
N
Chaves
Precisamos ter uma maneira de especificar como as entidades 
de um determinado conjunto de entidades são distinguidas. 
Conceitualmente, as entidades individuais são distintas; de uma 
perspectiva de banco de dados, no entanto, a diferença entre 
elas precisa ser expressa em termos de seus atributos.
Portanto, os valores atributos de uma entidade precisam ser 
tais, que possam identificar unicamente a entidade. Em outras 
palavras, nenhuma entidade em um conjunto de entidades pode 
ser exatamente o mesmo valor de outra entidade para todos os 
atributos (SILBERSCHATZ, 1999).
5
10
15
20
Unidade II
16R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Chave primária, chave estrangeira e chave candidata 
permitem, na modelagem de dados, identificar um conjunto 
dos atributos que são suficientes para distinguir uma entidade 
das outras. Também ajudam a identificar relacionamentos 
unicamente e, assim, distinguir relacionamentos uns dos 
outros.
Chave primária é aquela que indica uma chave 
candidata que é escolhida pelo projetista de banco de dados 
como o principal meio de identificar entidades dentro de um 
conjunto de entidades. Quaisquer duas entidades individuais 
no conjunto são proibidas de ter o mesmo valor nos atributos 
de chave ao mesmo tempo.
Chamamos de chave estrangeira aquela que surge quando 
um atributo de um relacionamento é chave primária em outro 
relacionamento.
Enfim, as chaves candidatas são aquelas que ocorrem 
quando um conjunto de um ou mais atributos, tomados 
coletivamente, permitem identificar unicamente uma entidade.
3.2.3 Entidades fortes e entidades fracas
É possível que um conjunto de entidades não tenha atributos 
suficientes para formar uma chave primária. Tal conjunto de 
entidades é nomeado como conjunto de entidades fraco. 
Um conjunto de entidades que possui uma chave primária é 
definido como conjunto de entidades forte.
Para ilustrar, considere o conjunto de entidades transação 
que possui três atributos: número-transação, data e quantia. 
Embora cada entidade transação seja distinta, transações em 
contas diferentes podem compartilhar o mesmo número de 
transação. Assim, este conjunto de entidades não tem uma 
chave primária e é, portanto, um conjunto de entidades fraco. 
Para que este conjunto de entidades fraco tenha significado, ele 
5
10
15
20
25
30
ADMINISTRAÇÃO DE BANCO DE DADOS
17 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
deve fazer parte de um conjunto de relacionamentos um-para-
muitos. Este conjunto de relacionamentos não deve ter atributos 
descritivos, uma vez que qualquer atributo requerido pode estar 
associado ao conjunto de entidade fraco.
Os conceitos de conjuntos de entidades forte e fraca 
estão relacionados às dependências de existência introduzidas 
anteriormente. Um membro de um conjunto de entidades 
forte é por definição uma entidade dominante, enquanto um 
membro de um conjunto de entidades fraco é uma entidade 
subordinada.
Embora um conjunto de entidades fraco não tenha uma chave 
primária, precisamos, todavia, de uma forma de distinção entre 
todas essas entidades no conjunto de entidades que dependa 
de uma entidade forte particular. O discriminador (ou chave 
parcial) de um conjunto de entidades fraco é um conjunto de 
atributos que permite que esta distinção seja feita. Por exemplo, 
o discriminador do conjunto de entidades fraco transação é o 
atributo número-transação, uma vez que para cada conta um 
número de transação identifica uma única transação.
A chave primária de um conjunto de entidades fraco é 
formadapela chave primária do conjunto de entidades forte, 
do qual ele é dependente de existência (ou dependência 
existencial), mais seu discriminador. No caso do conjunto 
de entidades transação, sua chave primária é número-conta, 
número-transação; onde número conta identifica a entidade 
dominante de uma transação e número-transação distingue 
entidades de transação dentro da mesma conta.
As entidades fracas são representadas por um retângulo 
duplicado. O conjunto de relações que identifica as entidades 
fracas é representado por losângulos duplicados. Os atributos que 
constituem a chave parcial (ou discriminadores) são sublinhados 
de forma tracejada.
5
10
15
20
25
30
Unidade II
18R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Enfim, na Fig. 3.4, o esquema geral de modelagem de dados 
usando MER:
Minimundo
Obtenção e análise de requisitos
Projeto conceitual
Projeto físico
Requisitos da base de dados
Esquema conceitual
(em um modelo de dados de alto nível)
Esquema conceitual
(em um modelo de dados de um SGBD específico)
Esquema Interno
(para o mesmo SGBD)
Mapeamento do modelo de dados
Independente de qualquer SGBD
SGBD específico
Fig. 3.4 - Esquema geral de modelagem de dados usando MER
3.3 Dicionário de dados
O Dicionário de dados é uma espécie de banco de dados 
isolado (mas um banco de dados do sistema, não um banco 
de dados do usuário); ele contém “dados sobre os dados” 
(também chamados metadados ou descritores) – ou seja, 
definições de outros objetos do sistema, em vez de somente 
“dados crus” (DATE, 2003).
Um dicionário completo também incluirá muitas 
informações adicionais mostrando, por exemplo, os 
programas que utilizam determinadas partes do banco de 
dados, os usuários que exigem certos relatórios, etc.
5
10
ADMINISTRAÇÃO DE BANCO DE DADOS
19 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Exemplo:
Entidade: Cliente
Atributo Classe Domínio Tamanho Descrição
Código_cliente Determinante Numérico
Nome Simples Texto 50
Telefone Multivalorado Texto 50 Valores sem as máscaras de entrada
Cidade Simples Texto 50
Data de 
nascimento Simples Data
Formato
dd/mm/aaaa
Analisando a tabela poderíamos descrever o seguinte 
dicionário de dados:
• cliente é o nome da entidade que foi definida no 
modelo;
• atributo são os atributos da entidade-cliente;
• classe determina o tipo do atributo;
• domínio determina o tipo da variável (ser numérico, texto, 
data e boleano);
• tamanho define a quantidade de caracteres que será 
necessária para armazenar o conteúdo da variável;
• descrição descreve o que é aquele atributo (opcional).
O Microsoft Excel também pode ser utilizado para descrever 
as tabelas do dicionário de dados. Não existe regulamento a 
respeito da ferramenta a ser utilizada.
3.4 Ferramentas CASE
3.4.1 Definição
Ferramentas computacionais são ferramentas que auxiliam 
na criação dos diagramas. O que se espera com o uso delas é 
acelerar o processo de representação dos diagramas, com suas 
tabelas e relacionamentos.
5
10
15
Unidade II
20R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Para Medeiros (2006), o processo de análise e definição do 
esquema de banco de dados é uma tarefa totalmente executada 
pelo especialista em bancos de dados. A ferramenta é um 
grande complemento no processo de desenhar os diagramas e 
documentá-los.
As ferramentas CASE, do inglês Computer-Aided Software 
Engineering, ou seja, “Engenharia de Software Auxiliada por 
Computador”, auxilia o analista na construção do sistema, 
prevendo, ainda na etapa de estudos, como será sua estrutura, 
quais serão suas entidades e relacionamentos. São elaborados 
vários diagramas que, em conjunto, constituem praticamente 
uma “planta” do sistema a ser desenvolvido.
As ferramentas CASE suportam anotações advindas da análise 
estruturada, surgida no final da década de 1970, que se funda 
basicamente em três modelos: o Modelo de Entidade Relacional, 
o Diagrama de Fluxo de Dados e o Dicionário de Dados.
Existem inúmeras ferramentas CASE disponíveis no mercado. 
Entre elas podemos citar: Rational Rose, ErWin, Oracle Designer, 
Genexus, Clarify, Dr. CASE, Visio, etc. Daremos atenção à 
ferramenta mais utilizada no mercado: a ErWin.
3.4.2 A ferramenta CASE ErWin
O CASE ErWin ficou muito tempo conhecido como ErWin? 
ERX, uma ferramenta leve e de fácil utilização. Porém, em 1998, 
a desenvolvedora do ErWin, a Logic Works, foi comprada pela 
Platinum. Na época, era disponibilizada a versão 2.5, que foi 
transformada na versão Platinum ErWin ERX 3.52. Essa versão 
existiu até 1999, quando a CA – Computer Associates – adquiriu 
a Platinum.
Quando a CA adquiriu o ErWin, incluiu o software em um 
pacote de ALM (Aplication Lyfe Cycle Management) chamado 
Allfusion, o ErWin passou a se chamar Allfusion ErWin Data 
5
10
15
20
25
30
ADMINISTRAÇÃO DE BANCO DE DADOS
21 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Modelere. Com isso, ganhou uma interface mais arrojada e 
alguns recursos muito interessantes.
Como duas ferramentas voltadas à entidade-relacionamento, 
com visões lógica e física do modelo, o diagrama é feito com 
recursos de arrastar e soltar, com todas as validações de chaves 
primárias e estrangeiras (Fig. 3.4).
Fig. 3.4 - Tela inicial do ErWin
As ferramentas suportam uma grande quantidade de banco 
de dados, como DB2, Oracle, Ingres, SQL Server, Sybase, Progress, 
Clipper, dBaseIII, dBaseIV, Access, FoxPro e Paradox.
O ErWin disponibiliza uma série de recursos muito 
interessantes, como:
• complete compare: uma ferramenta que simplesmente 
compara a estrutura de banco de dados com o MER, 
apontando as diferenças existentes;
• comando de impressão do DER: disponibiliza o 
redimensionamento da escala do diagrama, permitindo 
controlar e prever em quantas páginas será impresso o 
diagrama, sem alterar a posição das entidades;
5
10
15
Unidade II
22R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
• model sources: um modelo ou um projeto pode ser 
constituído de vários outros modelos, ou seja, pode ser 
criado um vínculo do ErWin e depois sincronizá-los. Isso 
é útil em casos típicos de compartilhamento de entidades 
entre vários projetos.
O ErWin possui um gerador de relatórios em vários formatos, 
de fácil manipulação e interação pelo usuário (Fig.3.5, 3.6, 3.7 e 
3.8).
A ferramenta é apenas um complemento às atividades de 
modelagem do banco de dados. Se o processo de modelar e 
analisar o problema for realizado de forma errada, o software 
fará a representação gráfica também errada.
Fig. 3.5 - Tela do ErWin – Biblioteca.
Fig. 3.6 - Tela do ErWin – Edição de campos.
5
10
ADMINISTRAÇÃO DE BANCO DE DADOS
23 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Fig. 3.7 - Tela do ErWin – Definição de cardinalidade.
Fig. 3.8 - Tela do ErWin – Geração de diversos bancos de dados.
24
Unidade III
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Unidade III
4 ADMINISTRAÇÃO DE SGBDs
As pessoas que trabalham com um banco de dados podem 
ser categorizadas como usuários de banco de dados ou 
administradores de banco de dados.
“Entre os usuários, existem quatro tipos diferentes, 
distinguidos pela maneira como esperam interagir com o sistema. 
Diversos tipos de interfaces com o usuário foram projetados” 
(SILBERSCHATZ, 1999:16):
• usuários leigos: sãousuários não avançados que interagem 
com o sistema chamando um dos programas de aplicação 
previamente escritos. A interface típica para usuários 
leigos é composta de formulários, na qual o usuário pode 
preencher campos apropriados no formulário. Também 
podem simplesmente ler relatórios gerados pelo banco de 
dados;
• programadores de aplicação: são profi ssionais de 
computação que escrevem programas de aplicação. Os 
programadores de aplicação podem escolher entre muitas 
ferramentas para desenvolver interfaces com o usuário. 
As ferramentas de RAD (Rapid Aplication Development) 
permitem que um programador de aplicação construa 
formulários e relatórios com um mínimo de esforço de 
programação;
• usuários avançados: interagem com o sistema sem 
escrever programas. Em vez disso, eles formam suas 
5
10
15
20
25
ADMINISTRAÇÃO DE BANCO DE DADOS
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
?-?sem-?mod
requisições em uma linguagem de consulta de banco 
de dados, Eles submetem cada uma dessas consultas a 
um processador de consulta, cuja função é desmembrar 
as instruções DML em instruções que o gerenciador 
de armazenamento entenda. Estão nesta categoria os 
analistas que submetem consultas para explorar dados no 
banco de dados;
• usuários especializados: são usuários avançados que 
escrevem aplicações de banco de dados especializadas, 
que não se encaixam na estrutura de processamento de 
dados tradicional. Entre essas aplicações estão os sistemas 
de projeto auxiliados por computador, sistemas de base 
de conhecimentos e sistemas especialistas, sistemas que 
armazenam dados com tipos de dados complexos (por 
exemplo, dados gráfi cos e dados de áudio) e sistemas de 
modelagem de ambiente.
A pessoa que tem controle central sobre o sistema é chamada 
de administrador de banco de dados (DBA). As funções de 
um DBA incluem:
• defi nição de esquema: o DBA cria o esquema de banco de 
dados original executando um conjunto de instruções de 
dados na DDL;
• estrutura de armazenamento e defi nição de método de 
acesso;
• modifi cação de esquema e de organização física: o DBA 
realiza mudanças no esquema e na organização física 
para refl etir as alterações das necessidades da empresa, 
ou modifi car a organização física de modo a melhorar o 
desempenho;
• concessão de autorização para acesso a dados: concedendo 
diferentes tipos de autorização, o DBA pode controlar 
partes do banco de dados em que os vários usuários podem 
5
10
15
20
25
30
26
Unidade III
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
acessar. As informações de autorização são mantidas em 
uma estrutura de sistema especial, a qual o sistema de 
banco de dados consulta toda vez em que alguém tenta 
acessar os dados no sistema;
• manutenção de rotina: exemplos da manutenção de rotina 
do DBA são:
- realizar backups periódicos do banco de dados, sejam em 
fi tas ou em servidores remotos, para prevenir perda de 
dados no caso de acidentes, como incêndio, inundação, 
etc.;
- garantir que haja espaço livre sufi ciente em disco para 
operações normais e aumentar o espaço em disco de 
acordo com o necessário;
- monitorar tarefas sendo executadas no banco de dados 
e assegurar que o desempenho não seja comprometido 
por tarefas muito onerosas submetidas por alguns 
usuários.
4.1 Segurança e administração - controle de 
acesso
Através do SGBD, o DBA pode implementar mecanismos 
de segurança baseados em garantias ou restrições de acesso 
com preenchimento de login e senha, permitindo o registro 
de acessos e operações a partir do período em que o usuário 
acessa o banco de dados até o momento em que ele encerra 
suas atividades (Fig. 4.1).
Fig. 4.1 - Conexão com SGBD cliente/servidor
5
10
15
20
27
ADMINISTRAÇÃO DE BANCO DE DADOS
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
?-?sem-?mod
O DBA pode atribuir a um usuário formas de autorização 
sobre partes do banco de dados. Por exemplo:
• autorização para ler dados;
• autorização para inserir novos dados;
• autorização para atualizar dados;
• autorização para excluir dados.
Cada um desses tipos de autorização é chamado de um 
privilégio (DATE, 2003). O DBA pode autorizar um usuário a 
todos, a nenhum ou a uma combinação de privilégios sobre 
partes específi cas de um banco de dados. Assim como também 
pode restringir o acesso a determinado banco de dados. Uma 
vez defi nido qual banco de dados poderá ser acessado, também 
defi ne quais tipos de operações poderão ser realizadas pelos 
usuários.
Os mecanismos de confi guração de privilégios são 
conhecidos como REVOKE e GRANT (revogação e garantia dos 
níveis), e podem ser implementados em grande parte de sistemas 
gerenciadores de banco de dados (Fig. 4.2).
Fig. 4.2 - Defi nindo privilégios no SQL Server 6.5
5
10
15
28
Unidade III
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
4.2 Recuperação (recovery)
O Recovery (recuperação), segundo DATE (2003:381) 
”em um sistema de banco de dados signifi ca basicamente a 
recuperação do próprio banco de dados: ou seja, restaurar o 
banco de dados a um estado que se sabe ser correto depois 
que alguma falha o leva a um estado incorreto ou, pelo menos, 
suspeito. E os princípios fundamentais em que se baseia essa 
recuperação são muito simples, e podem ser resumidos em uma 
palavra: redundância. Em outras palavras, o modo de garantir 
que o banco de dados de fato é recuperável é garantir que toda 
informação que ele contém possa ser reconstruída a partir de 
alguma outra informação armazenada de modo redundante em 
outro lugar do sistema”.
O sistema deve estar preparado para se recuperar não 
apenas de falhas puramente locais, como a ocorrência de 
uma condição de estouro (overfl ow) dentro de uma transação 
individual, mas também de falhas “globais”, como uma queda 
de energia. Por defi nição, uma falha local só afeta a transação 
em que a falha realmente ocorreu. Ao contrário, uma falha 
global afeta todas as transações em andamento no instante 
da falha e, portanto, tem implicações signifi cativas em todo o 
sistema. Essas falhas se enquadram em duas grandes categorias 
(DATE, 2003):
• Falhas do sistema (por exemplo, queda de energia), que 
afetam todas as transações em curso no momento, mas 
não danifi cam fi sicamente o banco de dados. Às vezes, 
uma falha do sistema é chamada de soft crash;
• Falhas da mídia (por exemplo, queda da cabeça de gravação 
sobre o disco), que causam danos ao banco de dados ou a 
uma parte dele, e afetam pelo menos todas as transações 
que, no momento, estão usando essa parte. Às vezes, uma 
falha da mídia é chamada de hard crash.
5
10
15
20
25
30
29
ADMINISTRAÇÃO DE BANCO DE DADOS
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
?-?sem-?mod
4.2.1 Recuperação de sistema
O ponto crítico com relação a falhas do sistema é o fato de 
que o conteúdo da memória principal é perdido (em particular, 
os buffers do banco de dados se perdem). Então, o estado 
exato de qualquer transação em curso no momento da falha 
deixa de ser conhecido; desse modo, tal transação não poderá 
nunca mais ser concluída com sucesso e deverá ser desfeita 
– isto é, retomada – quando o sistema for reinicializado. Além 
disso, também pode ser necessário refazer no momento da 
reinicialização certas transações concluídas com êxito antes 
da queda, mas que não conseguiram ter suas atualizações 
transferidas dos buffers do banco de dados para o banco de 
dados físico (DATE, 2003).
Segundo DATE,“o sistema mantém um log ou diário em fi ta 
ou (mais comumente) em disco, no qual são registrados detalhes 
de todas as operações de atualização – em particular, valores do 
objeto atualizado antes e depois de cada atualização, às vezes 
chamados de imagens antes e depois” (2003:383).
Surge aqui a questão óbvia: de que maneira o sistema 
saberá, no momento da reinicialização, quais transações devem 
ser desfeitas e quais devem ser refeitas? A resposta é a seguinte: 
em certos intervalos predeterminados – em geral, sempre que 
algum número preestabelecido de entradas é gravado no log 
– o sistema automaticamente marca um checkpoint (ponto de 
verifi cação). Marcar um checkpoint envolve:
a) gravar fi sicamente o conteúdo dos buffers do banco de 
dados físico;
b) gravar fi sicamente um registro de checkpoint especial no 
log físico.
O registro de checkpoint fornece uma lista de todas as 
transações que estavam em andamento no momento em que o 
5
10
15
20
25
30
30
Unidade III
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
checkpoint foi marcado. O sistema percorre o log do fi m para o 
início, desfazendo as transações; em seguida, ele percorre o log 
de novo para a frente, refazendo as transações.
A restauração do banco de dados a um estado correto 
refazendo o trabalho é chamada de recuperação direta. De 
modo semelhante, a restauração do banco de dados a um 
estado correto desfazendo o trabalho às vezes é chamada de 
recuperação inversa. Observe que a recuperação direta refaz 
as atualizações na ordem em que foram feitas originalmente, 
enquanto a recuperação inversa desfaz as atualizações na ordem 
inversa.
Finalmente, quando toda essa atividade de recuperação for 
concluída, então o sistema estará pronto para aceitar um novo 
trabalho.
4.2.2 Recuperação da mídia
A recuperação de uma falha desse tipo envolve basicamente 
a recarga ou a restauração do banco de dados a partir de 
uma cópia de backup. Em seguida, usa-se o log – em geral, 
tanto a parte ativa quanto a parte arquivada – para refazer 
todas as transações que se completaram desde que foi feita 
a última cópia de backup. Não há necessidade de desfazer 
as transações que ainda estavam em curso no momento 
da falha, pois, por definição, todas as atualizações dessas 
transações de qualquer modo foram “desfeitas” – perdidas 
(DATE, 2003).
A necessidade de ser capaz de efetuar a recuperação da 
mídia implica a necessidade de um utilitário de dump/restore 
(ou de descarga/recarga). A parte de dump desse utilitário 
é usada para criar cópias de backup do banco de dados por 
solicitação. Essas cópias podem ser mantidas em fita ou em 
outro meio de armazenamento de arquivos; não é necessário 
que estejam na mídia de acesso direto. Depois de uma falha 
5
10
15
20
25
30
31
ADMINISTRAÇÃO DE BANCO DE DADOS
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
?-?sem-?mod
de mídia, a parte de restauração do utilitário é usada para 
recriar o banco de dados a partir de uma cópia de backup 
especificada.
4.3 Replicação de dados
Replicação de banco de dados é a cópia dos dados de um 
banco de dados original para outro banco. Muitos bancos de 
dados comerciais hoje permitem replicação, que pode assumir 
uma das várias formas. Com a replicação mestre-escravo 
(master-slave), o banco de dados permite atualizações em um 
site primário e propaga automaticamente as atualizações para 
as réplicas em outros sites. As transações podem ler as réplicas 
em outros sites, mas não têm permissão para atualizá-las (Fig. 
4.3 e 4.4) (DATE, 2003).
Um recurso importante de tal replicação é que as 
transações não têm bloqueios em sites remotos. Para garantir 
que as transações executadas nos sites de réplica tenham 
uma visão consistente (mas talvez desatualizada) do banco 
de dados, a réplica deverá refletir um snapshot consistente 
com a transação dos dados no site primário; ou seja, a réplica 
deverá refletir todas as atualizações das transações até 
alguma transação na ordem de seriação, e não deverá refletir 
quaisquer atualizações de outras transações na ordem de 
seriação.
O banco de dados pode ser confi gurado para propagar 
as atualizações imediatamente após elas ocorrerem no site 
primário, ou propagar as atualizações apenas periodicamente.
A replicação mestre-escravo é particularmente útil para 
distribuir informações, por exemplo, de um escritório central 
para os escritórios das fi liais de uma organização. Outro uso 
para essa forma de replicação é na criação de uma cópia do 
banco de dados para executar grandes consultas, de modo que 
as consultas não interfi ram com as transações. As atualizações 
5
10
15
20
25
30
32
Unidade III
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
devem ser propagadas periodicamente – a cada noite, por 
exemplo – de modo que a propagação da atualização não 
interfi ra com o processamento da consulta.
Master Master
Fig. 4.3 - Servidores mestre estão ambos sincronizados transmitindo escrita, 
atualizações e transações em tempo real.
SlaveMaster
Fig. 4.4 - Servidores mestre-escravo estão ambos sincronizados transmitindo em 
tempo real.
O sistema de banco de dados Oracle admite uma instrução 
create snapshot, que pode criar uma cópia snapshot de uma 
relação consistente com a transação, ou de um conjunto de 
relações em um site remoto. Ele também admite o refresh 
do snapshot, que pode ser feito recalculando o snapshot 
ou atualizando-o de modo incremental. O Oracle admite 
refresh automático, seja de forma contínua ou em intervalos 
periódicos.
Com a replicação multimestre (também chamada 
replicação de atualização em qualquer lugar) as atualizações 
são permitidas em qualquer réplica de um item de dados e são 
propagadas automaticamente a todas as réplicas. Esse é o modelo 
básico usado para gerenciar os bancos de dados distribuídos. As 
transações atualizam a cópia local e o sistema atualiza outras 
réplicas de forma transparente.
Muitos sistemas de banco de dados oferecem uma forma 
alternativa de atualização: eles atualizam em um site, com a 
propagação lenta das atualizações para outros sites, em vez 
de aplicar imediatamente as atualizações a todas as réplicas, 
5
10
15
20
33
ADMINISTRAÇÃO DE BANCO DE DADOS
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
?-?sem-?mod
como parte de uma transação que realiza atualização. Os 
esquemas baseados na propagação lenta permitem que o 
processamento da transação (incluindo atualizações) prossiga 
mesmo que um site esteja desconectado da rede, melhorando 
assim a disponibilidade, mas, infelizmente, fazem isso a custo 
da consistência. Uma de duas técnicas normalmente é seguida 
quando a propagação lenta é usada:
• as atualizações nas réplicas são traduzidas para as 
atualizações em um site primário, que são propagadas 
lentamente a todas as réplicas. Esta técnica garante que 
as atualizações em um item sejam ordenadas em série, 
embora os problemas de seriação possam ocorrer, visto que 
as transações podem ler um valor antigo de algum outro 
item de dados e usá-lo para realizar uma atualização;
• as atualizações são realizadas em qualquer réplica e 
propagadas a todas as outras réplicas. Essa técnica pode 
causar ainda mais problemas, pois o mesmo item de dados 
pode ser atualizado simultaneamente em vários sites.
Alguns confl itos devido à falta de controle de concorrência 
podem ser detectados quando atualizações são propagadas 
para outros sites, mas resolver o confl ito envolve reverter as 
transações confi rmadas e a durabilidade das mesmas, portanto, 
nãoé nenhuma garantia. Além do mais, a intervenção humana 
pode ter de lidar com confl itos. Esses esquemas, portanto, 
deverão ser evitados ou usados com cuidado.
4.4 Formas de melhoria de desempenho
4.4.1 Simulação de desempenho
Para testar o desempenho de um sistema de banco de dados, 
mesmo antes que este seja instalado, podemos criar um modelo 
de simulação de desempenho. Cada serviço como CPU, disco, 
buffer e controle de concorrência, é modelado na simulação. Em 
5
10
15
20
25
34
Unidade III
Re
vi
sã
o:
 A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
vez de modelar detalhes de um serviço, o modelo de simulação 
só pode capturar alguns aspectos de cada serviço, como o tempo 
de serviço, ou seja, o tempo gasto para terminar de processar 
uma solicitação, uma vez que o processamento tenha se iniciado. 
Assim, a simulação pode modelar um acesso ao disco a partir 
apenas do tempo médio de acesso ao mesmo (DATE, 2003).
Como as solicitações para um serviço geralmente precisam 
esperar sua vez, cada serviço possui uma fi la associada no 
modelo de simulação. Uma transação consiste em uma série 
de solicitações. As solicitações são enfi leiradas à medida que 
chegam, e são atendidas de acordo com a política para esse 
serviço, na qual “o primeiro a chegar, é o primeiro a ser atendido”. 
Os modelos para serviços como CPU e discos conceitualmente 
operam em paralelo, levemos em conta o fato de que esses 
subsistemas operam em paralelo em um sistema real.
Quando o modelo de simulação para processamento de 
transação é criado, o administrador do sistema pode executar 
diversas experiências sobre ele. Ele pode usar experiências 
com transações simuladas chegando em diferentes taxas para 
descobrir como o sistema se comportaria sob diversas condições 
de carga. O administrador poderia executar outras experiências 
que variam os tempos de serviço para cada serviço, a fi m de 
descobrir a sensibilidade do desempenho de cada um deles. 
Os parâmetros do sistema podem ser variados, de modo que o 
ajuste do desempenho pode ser feito no modelo de simulação.
5
10
15
20
25
ADMINISTRAÇÃO DE BANCO DE DADOS
35 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
5
10
15
5 DEFINIR A MELHOR SOLUÇÃO DE BANCO DE 
DADOS PARA AS NECESSIDADES DA EMPRESA
5.1 O uso das tecnologias
5.1.1 O software livre
A tecnologia de banco de dados, assim como a informática 
em geral, vem sofrendo atualizações constantes e, uma das 
atividades do profissional de banco de dados é a de se manter 
informado sobre as atualizações do mercado no que se refere a 
novos produtos.
Medeiros (2006) afirma que nos últimos anos, a área 
de banco de dados sofreu uma grande modificação com 
a chegada das ferramentas gratuitas, ou de uso livre, como 
normalmente são chamadas. Tão importante quanto o fato de 
serem gratuitas, foi o fato de as ferramentas se apresentarem 
robustas e confiáveis, o que agradou muito o mercado de 
trabalho.
As ferramentas gratuitas estão baseadas na ideia de software 
livre, que tem como princípio: “software livre” é uma questão 
de liberdade, não de preço.
“Software livre” se refere à liberdade dos usuários com 
relação ao software, mais precisamente:
• a liberdade de executar o programa para qualquer 
propósito;
Unidade IV
Unidade I
36R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
• a liberdade de estudar como o programa funciona e 
adaptá-lo para as suas necessidades. Acesso ao código-
fonte é um pré-requisito para essa liberdade;
• a liberdade de redistribuir cópias de modo que você possa 
ajudar o seu próximo;
• a liberdade de aperfeiçoar o programa e liberar os seus 
aperfeiçoamentos, de modo que toda a comunidade se 
beneficie.
O software livre é uma tendência de mercado. As ferramentas 
atuais, como o MySQL, PostGreSQL, Firebird e outros, têm 
apresentado a cada ano versões mais confiáveis e amigáveis, 
que permitem ao usuário realizar as mesmas rotinas de outros 
bancos de dados proprietários com a mesma qualidade.
As ferramentas proprietárias existentes no mercado, como 
Oracle e MS-SQLServer, também têm sua grande contribuição 
no mercado de trabalho como ferramentas robustas, confiáveis 
e de larga utilização, principalmente pelas empresas de grande 
porte.
O mercado de banco de dados está em constante atualização 
e dessa forma abre espaço para todos os tipos de ferramentas. 
Isso é bom porque abre portas para os profissionais da área de 
tecnologia da informação, em especial aos com conhecimento 
em banco de dados. Um especialista em tecnologia da informação 
não é um especialista em ferramentas, mas em soluções. Logo, 
ele não deve se prender a fabricantes ou produtos e, sim, estar 
preparado para as constantes mudanças que o mercado deverá 
sofrer.
Apesar das mudanças, as ferramentas de banco de dados 
tendem a facilitar a vida do profissional de informática, tornando 
a sua produção maior e mais eficiente, evitando que ele tenha 
que editar comandos manualmente ou criar tabelas através de 
comandos extensos.
5
10
15
20
25
30
ADMINISTRAÇÃO DE BANCO DE DADOS
37 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
5.1.2 Ferramentas de SGBD
Veremos a seguir algumas ferramentas disponíveis no 
mercado de SGBD e suas principais características:
MySQL
O aplicativo é um sistema gerenciador de banco de dados 
relacional baseado em comandos SQL, que vem ganhando 
grande popularidade atualmente. Foi criado na Suécia por dois 
suecos e um finlandês: David Axmark, Allan Larsson e Michel 
Widenius, que trabalham juntos desde a década de 1980.
O sucesso do aplicativo deve-se em grande parte à fácil 
integração com linguagens de programação Web, como o PHP, 
e principalmente por se tratar de um banco de dados gratuito, 
ou seja, o usuário não tem custo algum para adquirir o produto, 
que pode ser baixado diretamente da Internet (Fig.5.1).
Fig. 5.1 - Visão geral do MySQL para Windows.
PostGreSQL
O aplicativo é um sistema de gestão de bases de dados 
relacionais, desenvolvido como projeto de software livre. Sua 
5
10
15
Unidade I
38R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
origem está de certo modo ligada ao projeto Ingres, desenvolvido 
na Universidade de Berkeley, Califórnia. O líder do projeto, 
Michael Stonebraker, um dos pioneiros das bases de dados 
relacionais, deixou a universidade em 1982 para comercializar o 
Ingres, acabando por regressar à Berkeley.
Em 1985, Stonebraker iniciou um projeto “pós-Ingres” 
com o objetivo de responder a muitos problemas envolvendo 
as bases de dados relacionais que surgiam. Esse novo projeto 
recebeu o nome de PostGres, que, apesar do parentesco, não 
partilhou o código-base com o Ingres, seguindo caminhos 
distintos.
Em 1993 o projeto PostGres foi oficialmente abandonado 
pela Universidade de Berkeley, mas devido ao fato de seu 
código-fonte estar sob licença gratuita, foi possível manter o 
seu desenvolvimento pela comunidade BSD1.
Em 1995 foi adicionado um interpretador SQL para substituir 
a linguagem QUEL (desenvolvida para a Ingres) e o projeto foi 
renomeado, primeiramente, para PostGres95 e mais tarde para 
PostGreSQL.
InterBase
O aplicativo InterBase é um gerenciador de banco de dados 
relacionais da Borland, mesmo fabricante das linguagens de 
programação Delphi, Borland C++ e Borland Java. Ele é uma 
opção alternativa aos bancos de dados tradicionais, como o 
SQLServer da Microsoft, e tem as vantagens de ser gratuito 
e código-aberto, o que significa que pode ser modificado e 
melhorado por qualquerusuário. Dessa forma, a ferramenta 
se mantém em constante evolução, sem custo algum aos seus 
usuários.
1 A licença BSD é uma licença de código aberto inicialmente 
utilizada nos sistemas operacionais do tipo Berkeley Software Distribution 
(um sistema derivado do Unix).
5
10
15
20
25
ADMINISTRAÇÃO DE BANCO DE DADOS
39 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
SQLite
O aplicativo SQLite é uma biblioteca em linguagem C que 
implementa um banco de dados SQL embutido. Programas que 
usam bibliotecas SQLite podem ter acesso a banco de dados 
SQL sem executar um processo separado. O SQLite lê e escreve 
diretamente no arquivo do banco de dados.
Algumas características do SQLite:
• software livre, domínio público e multiplataforma;
• não necessita de instalação, configuração ou administração;
• implementa a maioria dos padrões SQL;
• o banco de dados é guardado em um único arquivo;
• suporta bases de dados acima de 2 terabytes;
• não possui dependências externas.
MS SQLServer
O aplicativo MS SQLServer é um gerenciador de banco de 
dados fabricado pela Microsoft. É um SGBD muito robusto e 
bastante usado em empresas e grandes sistemas corporativos 
(Fig. 5.2).
Fig. 5.2 - Visão geral do Microsoft SQLServer.
5
10
15
Unidade I
40R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Oracle
O aplicativo é um sistema de banco de dados que surgiu no 
final dos anos de 1970, quando Larry Ellison vislumbrou uma 
oportunidade que outras companhias não haviam percebido ao 
encontrar uma descrição de um protótipo funcional de um banco 
de dados relacional e, ao descobrir que nenhuma empresa havia 
se empenhado em comercializar essa tecnologia. Então, Ellison 
e os cofundadores da Oracle Corporation, Bob Miner e Ed Oates, 
perceberam que havia um tremendo potencial de negócios no 
modelo de banco de dados relacional, tornando sua empresa a 
maior do mundo no ramo de software empresarial (Fig. 5.3).
A empresa oferece produtos de banco de dados, 
ferramentas e aplicativos, bem como serviços relacionados 
de consultoria, treinamento e suporte. A tecnologia Oracle 
pode ser encontrada em quase todos os setores do mundo 
inteiro e nos escritórios de 98 das empresas citadas na lista 
da Fortune 100.
Fig. 5.3 - Visão geral do Oracle Enterprise Manager.
5.2 Requisitos de software – arquitetura 
cliente/servidor
Para DATE (2003), o objetivo geral de sistemas de banco de 
dados é fornecer suporte ao desenvolvimento e à execução de 
aplicações de bancos de dados. Portanto, sob um ponto de vista 
5
10
15
20
ADMINISTRAÇÃO DE BANCO DE DADOS
41 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
do mais alto nível, um sistema desse tipo pode ser considerado 
como tendo uma estrutura muito simples em duas partes, 
consistindo em um servidor, também chamado back end, e um 
conjunto de clientes, também chamados front ends, ou seja:
1. O servidor é o próprio SGBD. Ele admite todas as funções 
básicas do SGBD (definição de dados, manipulação de dados, 
segurança e integridade de dados, etc.). Em outras palavras, o 
termo “servidor”, neste contexto, é tão somente um outro nome 
para o SGBD;
2. Os clientes são as diversas aplicações executadas em cima 
do SGBD – tanto as aplicações escritas por usuários quanto 
as aplicações internas (built-in, ou seja, aplicações fornecidas 
pelo fabricante do SGBD ou por terceiros). No que se refere ao 
servidor, é claro que não existe diferença alguma entre aplicações 
escritas pelo usuário e aplicações internas; todas elas empregam 
a mesma interface para o servidor. Observamos também que 
certas aplicações especiais chamadas “utilitárias”, poderiam 
constituir uma exceção, já que elas às vezes poderiam ter de 
operar diretamente no nível interno do sistema. Esses utilitários 
normalmente são considerados componentes internos do SGBD, 
em vez de aplicações no sentido mais comum.
SGBD
Aplicações Máquina-cliente
Acesso remoto 
transparente
Máquina-servidora
Fig. 5.1 – Cliente(s) e servidor funcionando em máquinas diferentes.
5
10
15
20
Unidade I
42R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Como podemos observar na Figura 5.1, o termo cliente/
servidor, embora seja uma expressão estritamente relacionada 
à arquitetura, passou a ser quase um sinônimo da disposição 
ilustrada, na qual o cliente e o servidor funcionam em máquinas 
diferentes.
Máquinas-cliente
Rede de 
comunicações
Fig. 5.2 – Uma máquina-servidora, várias máquinas-cliente.
De fato, como nos mostra DATE (2003), há muitos argumentos 
em favor de um esquema desse tipo:
- O primeiro é basicamente o argumento mais comum 
sobre o processamento paralelo: especificamente, duas ou 
mais máquinas estão sendo agora aplicadas na tarefa geral, 
enquanto o processamento do servidor (o banco de dados) e 
do cliente (a aplicação) está sendo feito em paralelo. Assim, 
o tempo de resposta e a vazão (throughput) devem ser 
melhorados.
- Além disso, a máquina-servidora pode ser uma máquina 
feita por encomenda para se ajustar à função do SGBD (uma 
5
10
15
ADMINISTRAÇÃO DE BANCO DE DADOS
43 R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
“máquina banco de dados”) e pode assim fornecer melhor 
desempenho ao SGBD.
- Do mesmo modo, a máquina-cliente poderia ser uma 
estação de trabalho pessoal, adaptada às necessidades do 
usuário final e, portanto, capaz de oferecer interfaces melhores, 
alta disponibilidade, respostas rápidas e, de modo geral, maior 
facilidade de utilização para o usuário.
- Várias máquinas-cliente distintas poderiam ser capazes (na 
verdade, normalmente serão capazes) de obter acesso à mesma 
máquina-servidora. Assim, um único banco de dados poderia 
ser compartilhado entre vários sistemas-cliente distintos, como 
pode ser visto na Figura 5.3.
Prosseguindo com o exemplo do banco, é muito provável 
que os usuários de uma agência ocasionalmente tenham de 
obter acesso a dados armazenados em outra agência. Portanto, 
observe que as máquinas-cliente poderiam ter seus próprios 
dados armazenados, e a máquina-servidora poderia ter suas 
próprias aplicações. Dessa forma, cada máquina atuará como 
um servidor para alguns usuários e como cliente para outros, 
como na Figura 5.3; em outras palavras, cada máquina admitirá 
um sistema de banco de dados inteiro.
Além dos argumentos anteriores, DATE (2003) complementa 
observando que existe também o fato de que a execução do(s) 
cliente(s) e do servidor em máquinas diferentes corresponde 
ao modo como as empresas operam na realidade. É bastante 
comum que uma máquina (um banco, por exemplo) opere muitos 
computadores, de tal modo que os dados correspondentes a 
uma parte da empresa sejam armazenados em um computador 
e os dados de outra parte da empresa sejam armazenados em 
outro computador.
5
10
15
20
25
30
Unidade I
44R
ev
is
ão
: A
m
an
da
: D
ia
gr
am
aç
ão
: L
éo
 0
2/
06
/0
9 
- 
Rede de 
comunicações
Clientes
Servidor
Clientes
Servidor
Clientes
Servidor
Clientes
Servidor
Clientes
Servidor
Fig. 5.3 – Cada máquina pode executar tanto(s) cliente(s) como o servidor.
Referências bibliográficas
COUGO, P. Modelagem conceitual e projetos de banco de 
dados. Rio de Janeiro: Campos, 1997/ 2004.
DATE, C.J. Introdução a Sistemas de Bancos de Dados. Rio de 
Janeiro: Elsevier, 2003.
RAMEZ E.E.; SHAMKANT, E. Sistemas de Banco de Dados. São 
Paulo: Addison-Wesley, 2005.
MEDEIROS, M. Banco de dados para sistemasde informação. 
Florianópolis: Visual Books, 2006.
SILBERSCHATZ, A.; KORTH, H.F.; SUDARSHA, S. Sistema de 
Banco de Dados. São Paulo: Makron, 1999.