ARQUITETURA DE SISTEMAS DE BANCO DE DADOS

Prévia do material em texto

Introdução aos conceitos de arquitetura de um sistema gerenciador de banco de dados (SGBD)
Demonstrar as características da arquitetura de um SGBD
Dados e Informação
Armazenar dados com intenção de gerar informações para análise e tomada de decisões vem cada vez mais ganhando atenção no mercado de tecnologia, esta necessidade em se realizar a transformação de dados isolados em algo substancial ao apoio a uma organização empresarial tem destaque na área de banco de dados. Além de uma forma adequada para definir o armazenamento destas informações, os usuários desejam realizar operações sobre esta coleção de dados como, adicionar, recuperar, atualizar ou modificar mediante as necessidades organizacionais.
O planejamento da construção e a administração da estrutura que terá como função gerir estes dados também tem uma relevância importante para que alcance os objetivos desta tecnologia que é o Sistema Gerenciador de Banco de Dados.
Estrutura do SGBD
Ao ser mencionada a palavra Arquitetura deve ser levado em consideração alguns fatores que implicam em sua criação, como o ambiente do banco de dados. Um Sistema Gerenciador de Banco de dados reúne um conjunto de programas que elevam o nome de coleção. Esta tem por competência gerir todo o mecanismo que envolve sua estrutura.
Desenvolver um Banco de Dados envolve a especificação detalhada dos dados, do processo de armazenamento no meio físico, administração das possíveis ocorrências em tempo de execução dos processos envolvidos nas transações solicitadas pelos usuários de toda a sua estrutura.
Ferramentas de um SGBD
Arquitetura – Três Esquemas
Esta abordagem demonstra características importantes existentes na manipulação administrativa de um  banco de dados:
1) separação de programas e dados (independência de dados e operação de programas);
2) suporte a múltiplas visões (views) de usuários;
3) uso de catálogo para armazenar a descrição do banco de dados (esquema).
Este tópico será demonstrará a arquitetura para os sistemas de banco de dados.
A finalidade da arquitetura de três-esquemas é separar o usuário da aplicação do banco de dados físico. Os esquemas podem ser definidos por três níveis:
1. O nível interno (esquema interno)  
      2. O nível conceitual (esquema conceitual)
     3. O nível externo (visão-view) 
Arquitetura três esquemas
Modelo de dados, Instância, Esquema
Apresentação de estrutura interna o SGBD
A utilização do banco de dados oferece certas características como a abstração dos dados, permitindo ocultar detalhes do armazenamento de dados desnecessários para a maioria dos usuários de bancos de dados.
Um modelo de dados tem como objetivo demonstrar a estrutura lógica e física de um banco de dados, seus relacionamentos, tipos de dados e restrições. Também podem ser conhecidos como estrutura ou nível, se dividindo em 2 tipos:
· Alto Nível ou modelo de dados conceitual ou ainda modelo Entidade-Relacionamento, o seu principal conceito é uma projeção dos dados que deixa o mais próximo possível da visão que o usuário tem dos dados.
· Baixo Nível ou modelo de dados físico, é o que fornece uma visão mais detalhada do modo como os dados estão armazenados no computador.
 
Nível Alto de uma estrutura do SGBD
	Modelo de Baixo Nível
	CLIENTES
	Codigo
	Nome
	DataNascimento
	10
	Ana Beatriz
	10/12/2000
	20
	 Claudio Marques
	18/07/1980
	50
	Silvana Correa
	01/04/2001
	TELEFONES
	Cod_Clie
	Fone
	Tipo
	10
	24808080
	Residencial
	20
	62334545
	Residencial
	20
	980112377
	Celular
	10
	962338765
	Celular
	30
	951225300
	Celular
 
Esquema
Em um projeto que representa o modelo de dados é importante destacar as particularidades existentes entre a descrição do banco de dados e o banco de dados propriamente dito. A descrição ou esquema do banco de dados é definido na fase de desenvolvimento do projeto do banco de dados e não se espera que possua alterações frequentes.  A maioria dos modelos de dados apresenta convenções de exibição de esquemas utilizando diagramas próprios da área ou oriundos de ferramentas. Os diagramas esquemáticos demonstram algumas características relevantes àquela situação, como os nomes dos tipos de registro e itens de dados, além de alguns tipos de restrições.
Aos aspectos ou dados que sofrem alterações frequentemente, por exemplo, os dados mudam todas as vezes que adicionamos um novo registro são chamados de estado do banco de dados ou instantâneos (snapshot).
Esquema de um SGBD
Instancia
As instâncias são formadas no instante que há a execução de algum processo com os dados armazenados no banco por um determinado tempo onde o resultado de demonstra o processamento, neste instante é formada a instância de banco de dados, sendo alterada toda vez que uma alteração na base de dados é realizada.
A arquitetura de um SGBD tem como principal objetivo, separar aplicações do usuário dos dados físico que são divididos nos esquemas abaixo:
· Nível interno ou esquema interno - modelo de dados que mostra a estrutura de armazenamento físico do banco de dados, os detalhes dos dados guardados e os caminhos de acesso.
· Nível conceitual ou esquema conceitual - descrição total da estrutura do banco de dados, mas não exibe detalhes dos dados guardados no banco de dados.
Nível externo ou esquema de visão - descreve as visões do banco de dados para um grupo de usuários que mostra quais usuários terão acesso a esse banco.
Organização e acesso do SGBD
Descrever as estruturas dos servidores de banco de dados
Servidores de banco de dados
Ao ser estudado o termo arquitetura, é comum ser referenciada a forma como os aplicativos computacionais são estruturados e como os hardwares estão dispostos e são utilizados. Devido a grande evolução atual e o barateamento dos equipamentos de informática, os enormes e caros mainframes em termos e necessidade estão sendo substituídos por pequenos, mas potentes computadores. Os sistemas computacionais também acompanharam essa evolução, sendo desenvolvidos sobre arquiteturas flexíveis, eficientes e abertas.  Mas esta escolha de tecnologia é cercada de perguntas e dúvidas, como por exemplo: O que é necessário para promover a implementação de uma estrutura de SGBD? Por isso há necessidade de ser conhecer as possibilidades existentes, como os servidores de banco de dados.
Arquitetura de banco de dados centralizada
Este modelo vem sendo utilizado durante anos também chamado de sistema centralizado, tem como composição um servidor e vários terminais que possuem pouco poder de processamento, geralmente um monitor e um teclado conectados a um grande computador “mainframe” com grande capacidade de processar e armazenar os dados. Esta  arquitetura tem a característica de possuir grandes investimentos tanto na aquisição de equipamentos como na manutenção dos mesmos. Considerando a utilização de um sistema de gerenciamento de banco de dados, ele e todos os seus aplicativos são hospedados no servidor e são acessados pelos terminais conectados ao servidor, onde  todo o processamento dos dados é realizado no computador central. 
Arquitetura centralizada
Vantagens: Um único servidor fornece alto grau de segurança, concorrência e controle de cópias de segurança e recuperação. Não existe a necessidade de junções distribuídas, já que todos os dados estão em um único servidor.
Desvantagens: Todos os acessos aos dados realizados por outro que não seja o servidor onde o banco de dados está, gera alto custo de comunicação. Criação de um “gargalo”, dependendo da quantidade de acessos simultâneos. Podem acontecer problemas de disponibilidade dos dados se o servidor sair do ar.
Arquitetura de banco de dados descentralizada
Esta arquitetura os dados são armazenados em pelo menos dois servidores, um que recebe os dados em sua totalidade e outro (s) são mantidos parte do banco de dados. Todo tipo de transação que é realizada, é feita primeiro no servidor local antes de ser atualizado o servidor central. 
Arquitetura descentralizada
Vantagens: Autonomia, custo e disponibilidade dos dados.
Desvantagens: Preocupação com a segurança, concorrênciae cópias de segurança dos dados.
Arquitetura de banco de dados distribuída
A arquitetura distribuída tem como característica a subdivisão dos dados, o compartilhamento entre vários computadores e a sua atualização feita através de um sincronismo entre os computadores pertencentes ao circuito de distribuição, ela utiliza vários SGBD`s que são espalhados pelos servidores,  contendo dados replicados em vários lugares em que bancos de dados diferentes são consultados ao mesmo tempo por um mesmo usuário. 
Arquitetura distribuída
Vantagens: Diferentes SGBD`s, diferentes tipos de computadores, possibilidade de acessar os dados de vários computadores como se fosse de apenas um só.
Desvantagem: Esforço computacional para que seja mantida a consistência dos dados e a sua segurança.
 Arquitetura de banco de dados replicada
Na replicação os dados são armazenados em servidores replicados permitindo que a falha de um determinado computador possa ser contornada por outro que irá substituí-lo. O banco de dados primário é igual ao banco de dados secundário. As transações atualizam primeiro o banco de dados primário para depois ser atualizado o banco de dados secundário. 
Arquitetura replicada
Vantagens: Custo de comunicação reduzido para o acesso aos dados apenas para leitura. Melhor disponibilidade caso um servidor saia do ar, o outro possui a replicação do mesmo banco entra em ação.
Desvantagens: O controle de concorrência em diversos bancos quando os dados das tabelas replicadas são atualizados.
Arquitetura de banco de dados paralela
Na arquitetura paralela é utilizado o conceito trabalho  com vários servidores simultaneamente sobre os seus respectivos bancos de dados para a obtenção de um rápido resultado.
Toda unificação e distribuição é realizada por um hardware que tem o papel de roteamento, fazendo com que o particionamento seja de dois tipos:
HASH: No particionamento HASH as tabelas são particionadas igualmente segundo uma chave de hashing. A sua utilização é ideal para aplicativos que enfatizam o acesso associado.
RANGER: No particionamento RANGER as tabelas são divididas por vários valores de chaves. A sua utilização é ideal para aplicações que enfatizam a busca pela chave de particionamento.
ESQUEMA: As tabelas são distribuídas entre vários servidores e a sua utilização é ideal quando se possui grandes quantidades de tabelas pequenas.
Arquitetura paralela
Arquitetura de um SGBD
Descrição interna da arquitetura de um SGBD
Devo ou não usar um SGBD
Ter ou não um SGBD
Para demonstrar a necessidade de uso, segue um exemplo de arquivos tradicionais versus banco de dados.
Em uma situação onde se é utilizado o tradicional processamento de arquivos, cada usuário define e utiliza os arquivos necessários para uma aplicação específica, como parte da programação da aplicação. Por exemplo, a secretaria de uma escola que administra as notas, pode manter um arquivo para os alunos e suas notas. Pode usar programas para imprimir um histórico do aluno e colocar novas notas no arquivo como parte da aplicação. O departamento de contabilidade pode controlar os dados relacionados às mensalidades e pagamentos dos alunos.  Partindo do suposto que ambos tem o mesmo objetivo de uso dos arquivos, eles possuem o mesmo interesse nos dados sobre os estudantes, mas cada um mantém suas informações em arquivos separados e os programas que manipulam esses arquivos. Isso acontece porque cada um deles precisa de alguns dados e não de todos os dados que cada um deles possuem. Este modelo de trabalho pode causar inúmeros problemas, principalmente com relação a confiança dos dados, visto que cada um possuí um arquivo independente do outro.
Essa redundância, na definição e armazenamento dos dados, resultam em um espaço de armazenamento desperdiçado e em esforços repetitivos para manter os dados comuns atualizados. Na abordagem utilizando um banco de dados, um único repositório de dados é definido uma única vez, mantido e então acessado por vários usuários.
As principais características da abordagem de um banco de dados versus a abordagem de processamento de arquivos são as seguintes:
•  Natureza autodescritiva do sistema de banco de dados.
•  Isolamento entre os programas e os dados, e a abstração dos dados.
•  Suporte para as múltiplas visões dos dados.
•  Compartilhamento de dados e processamento de transações de multiusuários.
Processamento tradicional versus banco de dados
Natureza Autodescritiva do Sistema de Banco de Dados
A abordagem de um banco de dados é que seu sistema não possui apenas o banco de dados, mas também uma completa definição ou descrição da estrutura desse banco de dados e suas restrições. Essa definição está armazenada no catálogo do SGBD, que contém informações como a estrutura de cada arquivo, o tipo e o formato de armazenamento de cada item de dado e várias restrições sobre os dados. A informação armazenada no catálogo é chamada metadados.
Isolamento entre os Programas e Dados e Abstração de Dados
Com relação ao processamento tradicional de arquivos, a estrutura do arquivo de dados está embutida no programa da aplicação. Qualquer mudança na estrutura de um arquivo pode exigir alterações de todos os programas que acessam esse arquivo. Ao contrário, os programas para acesso ao SGBD não exigem essas alterações na maioria dos casos, a estrutura dos arquivos de dados é armazenada no catálogo do SGDB separadamente do programa de acesso.
Suporte para as Múltiplas Visões dos Dados
Um sistema de banco de dados tende a possuir muitos usuários, cada usuário em atuação pode solicitar diferentes e diversas visões ou relatórios deste sistema. Uma visão pode ser um subconjunto de dados, que são derivados dos arquivos do banco de dados. Alguns usuários podem não saber se os dados a que eles se referem são armazenados ou não. Um SGBD multiusuários possui diversas aplicações distintas, para facilitar a definição das visões. Por exemplo, um usuário do banco de dados da escola pode estar interessado somente em acessar e imprimir o histórico de cada aluno; um segundo usuário, interessado em checar se os alunos cumpriram todos os pré-requisitos de cada curso para o qual se matricularam.
Compartilhamento de Dados e o Processamento de Transação Multiusuários
O sistema multiusuário possui como objetivo que vários usuários acessem o banco de dados ao mesmo tempo. Isso é essencial se os dados para as várias aplicações estão integrados e mantidos em um único banco de dados. O SGBD gerencia os processos através um software de controle de concorrência para garantir que muitos usuários, ao tentar atualizar o mesmo dado, o façam de um modo controlado assegurando os resultados das atualizações sejam corretos. Por exemplo, quando muitos atendentes tentam reservar um lugar em um vôo, o SGBD deve garantir que cada assento possa ser acessado somente por um atendente de cada vez, para fazer a reserva de apenas um passageiro. Esses tipos de aplicações são, normalmente, denominados aplicações de processamento de transações on-line — online transaction processing (OLTP).
A transação é um programa em execução ou processo que inclui um ou mais acessos ao banco de dados, como a leitura ou a atualização de registros. Cada transação deve executar um acesso logicamente correto ao banco de dados, se executado sem a interferência de outras transações. O SGBD deve garantir várias propriedades da transação. A propriedade de isolamento garante que cada transação possa ser efetuada de forma isolada de outras transações; mesmo centenas de transações podem ser executadas simultaneamente. A propriedade de atomicidade garante que todas as operações em um banco de dados, em uma transação, sejam executadas ou nenhuma delas o seja.
As características precedentes são muito importantes para distinguir um SGBD de um software tradicional de processamento de arquivos. 
Sistema Gerenciador de Banco de Dados
Parâmetros e Arquivos
O profissional que tem o cargo de administrador assume total responsabilidade na administração de banco de dados tem com tarefas: instalar, configurar,monitorar e solucionar problemas de um SGBD (Sistema Gerenciador de Banco de Dados), ou seja suas responsabilidades:
- Projeto lógico do banco de dados: criação do esquema lógico usando a DDL;
- Definição de checagem de segurança e integridade;
- Decisão de como os dados são representados na base de dados armazenada;
- Projeto físico da base de dados;
- Definição de procedimentos de recuperação;
- Monitoração do desempenho;
- Contato com usuários para averiguação de disponibilidade dos dados por eles - requisitados e ajuda na determinação e resolução de problemas;
- Ajustes apropriados à medida que ocorram mudanças de requisitos.
Tarefas do DBA
Parameter Files (Arquivos de parâmetros)
Este arquivo de parâmetro de servidor é um arquivo binário que funciona como um repositório para os requisitos de inicialização. O arquivo pode residir na máquina onde o servidor de banco de dados é executado.
Trace Files (Arquivos de rastreamento)
Também conhecidos como TRC, que é uma extensão de um arquivo de depuração usado pelo software de banco de dados. O TRC tem como objetivo o rastreamento através de log de eventos onde a descrição das transações que teriam ocorrido no banco de dados. Eles são normalmente utilizados para diagnosticar erros ou para a depuração do banco de dados e podem ser abertos pela maioria dos editores de texto.
Alert Files (Arquivos de alerta)
Em um banco de dados os erros também são monitorados, o arquivo de log de alerta (alert.log) é um registro cronológico de mensagens e erros escritos pelo banco de dados.
As mensagens típicas encontradas neste arquivo referem-se: a inicialização do banco de dados, desligamento, opções de registro, erros de espaço, entre outras. É um arquivo deve ser constantemente monitorado para observação de ocorrências existentes a partir de mensagens e corrupções inesperados.
O log de alerta é um registro cronológico de mensagens e erros, e inclui os seguintes itens:
Todos os erros internos (ORA-600), erros de bloco de corrupção (ORA-1578), e os erros de impasse (ORA-60) que ocorrem operações administrativas, tais como CREATE, ALTER e DROP e inicialização, desligamento entre outros.
Configuração SGBD
Independência de dados
Conhecer as diferentes formas de Independência de dados em um SGBD
Definição para independência de dados em banco de dados:
É a capacidade de mudar o esquema em um nível do sistema de banco de dados sem que ocorram alterações do esquema no próximo nível mais alto. Existem dois tipos de independência de dados:
Definição de independência
Independência de dados lógica:
É a possibilidade da alteração do esquema conceitual sem mudar o esquema externo ou os programas. Por exemplo realizar uma modificação no esquema conceitual para expandir o banco de dados (adicionando um tipo de registro ou item de dados), alterar as restrições ou reduzir o banco de dados (removendo um tipo de registro ou item de dados). No último caso, os esquemas externos que se referem apenas aos dados remanescentes não precisariam ser afetados.
Somente a definição da visão e os mapeamentos precisam ser alterados em um SGBD que suporta a independência lógica dos dados. As alterações nas restrições podem ser aplicadas ao esquema conceitual, sem afetar os esquemas externos ou os programas.
Independência Lógica de dados
Independência física de dados:
É a capacidade de mudar o esquema interno sem ter de alterar o esquema conceitual. As mudanças no esquema interno podem ser necessárias para que alguns arquivos físicos possam ser reorganizados — exemplo: criação de estruturas de acesso adicionais.
Este estilo de  arquitetura de três-esquemas torna mais fácil a independência de dados, tanto física quanto lógica. 
Independência Fisica de dados
Um pouco mais sobre a independência e as características de um SGBD
Maneabilidade : pessoas que não conhecem a base de dados devem ser capazes de fazer o seu pedido sem fazer referência a elementos técnicos da base de dados
Rapidez dos acessos : o sistema deve poder fornecer as respostas aos pedidos o mais depressa possível, o que implica algoritmos de investigação rápidos
Administração centralizada : o SGBD deve permitir ao administrador poder manipular os dados, inserir elementos, verificar a sua integridade de maneira centralizada
Limitação da redundância : o SGBD deve poder evitar, na medida do possível, informações redundantes, a fim de evitar por um lado um desperdício do espaço memória mas também erros
Verificação da integridade : os dados devem ser coerentes entre eles, ainda mais quando os elementos fazem referência a outros, estes últimos devem estar presentes
Partilha dos dados : o SGBD deve permitir o acesso simultâneo à base de dados por vários utilizadores
Segurança dos dados : o SGBD deve apresentar mecanismos que permitam gerir os direitos de acesso aos dados de acordo com os utilizadores
Arquivos, memórias, abstração de dados
Conceitos e objetivos sobre arquivos e gerenciamento de espaço em SGBD
Em tempos atuais a grande maioria das organizações, possuem quantidades cada vez maiores de dados e informações a armazenar, porém a manipulação destes dados para gerar informações se tornou impossível de ser realizada manualmente (via papéis, principalmente), Com o intuito de agilizar este processo usa-se a base de dados que recorre a uma das tecnologias de informação de maior sucesso e confiança. Contudo, sua administração deve ser a mais confiável possível permitindo a criação de arquivos para se armazenar os dados, gerenciamento de memória para maior rapidez e a extração de relatórios de forma mais clara possibilitando ajuda na tomada de decisão. O uso da boa administração faz com que este processo tenha o melhor desempenho  da estrutura de armazenamento, portanto ter atençãopara certas coisas são de suma importância, como:
DataFiles
A criação de uma estrutura física obedece a uma sequencia de parâmetros no desenvolvimento. O primeiro passo acontece no nível do sistema operacional, onde o armazenamento é criado, chamado datafiles (como se fosse uma pasta no sistema operacional), estes são arquivos com tamanhos definidos e que podem ser “vistos” no sistema operacional através de comandos simples como “ls -l” (UNIX) ou “dir” (MS-Windows), após a fase física a criação lógica tem seu desenvolvimento, são as tablespaces. Existem neste processo uma relação entre as estruturas lógica (tablespaces) e física (datafiles), onde cada tablespace pode ser constituída por um ou mais datafiles porém, cada datafile pode “servir” a uma e somente uma tablespace. 
Estrutura física - DataFile, estrutura lógica - TableSpace
Fonte: Documentação Oracle
Databases, tablespaces e datafiles têm diferenças:
Databases, é uma ou mais unidades lógicas de armazenamento chamadas de tabela, que coletivamente armazenam todos os dados do banco de dados.
Tablespaces, são um ou mais arquivos de dados, ou seja, estruturas físicas em conformidade com o sistema operacional no qual se está sendo executado.
Datafiles, arquivos de dados das tabelas do banco de dados. Por exemplo, o mais simples banco de dados teria um espaço de tabela e um arquivo de dados. Outra base de dados pode ter três espaços de tabela, cada um consistindo de dois ficheiros de dados (para um total de seis arquivos de dados).
Control Files
O arquivo de controle de banco de dados é um pequeno arquivo binário necessário para o banco de dados. Este arquivo de controle é atualizado continuamente durante o uso do banco de dados, estando sempre disponível para a escrita no instante que o banco de dados é aberto. Se por algum motivo o arquivo de controle não está acessível, então o banco de dados não pode funcionar corretamente.
Cada arquivo de controle é associado a apenas um banco de dados.
Conteúdo controle de arquivo
Um arquivo de controle contém informações sobre o banco de dados associado que é necessário para o acesso de uma instância, para start e durante a operação normal. Informações sobre o arquivo de controle só pode ser alterado pelo próprio SGBD; nenhum administrador de banco de dados ou o usuáriopode editar um arquivo de controle.
Um arquivo de controle contém as seguintes informações:
· O nome do banco de dados;
· O timestamp da criação do banco de dados;
· Os nomes e localizações de arquivos de dados associados e arquivos de log;
· Informações sobre o tablespace;
· O histórico do log;
· Informações de log arquivado;
· Conjunto de backup e informações do backup;
· Arquivo de dados de backup;
· Cópia dos dados do Datafile;
· O número de seqüência de log atual;
· Informações Checkpoint;
Por exemplo: cada vez que um arquivo de dados ou um arquivo de log redo é adicionado, renomeado  ou retirado da base de dados, o arquivo de controle é atualizado para refletir essa mudança na estrutura física.
Gerenciamento de arquivos
Temp Files
O Temp (temporário) é o local onde o SGBD armazena todas as suas tabelas temporárias. Como exemplo pode ser representado pelo quadro branco ou papel de rascunho do banco de dados. Este arquivo do banco de dados é utilizado armazenar objetos transitórios durante as classificações e agrupamentos de dados durante a execução de uma instrução SQL contendo as cláusulas ORDER BY e GROUP BY, entre outras. É importante dizer também que os dados de sessão das tabelas temporárias globais (Global Temporary Tables) também ficam no tablespace TEMP. Assim como o tablespace SYSTEM é o tablespace mais crítico do banco dados, o tablespace TEMP é o menos crítico do banco de dados exatamente porque armazena apenas os segmentos temporários durante as operações de classificação de dados e, como tal, no caso de uma falha, ele pode simplesmente ser dropado e recriado, em vez de ser restaurado e recuperado.
Arquivos temporários
Processos realizados no SGBD
Gerenciamento de Processos no SGBD
Pode- se entender por Processamento de Dados (tradução do termo inglês Data Processing) em uma série de atividades sequencialmente realizadas, com o objetivo de produzir informações. Inicialmente têm-se os dados que podem ser definidos como a matéria-prima originalmente obtida de uma ou mais fontes e a informação, como o resultado do processamento, isto é, o dado processado ou "acabado".
Entrada - Processamento - saída
Partindo desta analogia o significado de processo em um SGBD pode ser comparado à definição utilizada nos sistemas operacionais que são execuções de tarefas para que o conjunto de programas envolvidos para obtenção do resultado final seja alcançado. Neste raciocínio alguns processos devem ser destacados:
Redo Log Files
Preparado para recuperar da ocorrência de falhas.....
A estrutura mais importante para as operações de recuperação é o log de redo, que tem como estrutura o trabalho com dois ou mais arquivos pré-alocados, com objetivo de armazenarem todas as alterações feitas ao banco de dados à medida que ocorrem. Cada instância de um banco de dados tem um log redo associado para proteger o banco de dados em caso de uma falha da instância.
Recuperação de falhas
Fonte: Elaborado pelo professor conteudista.
Essa estrutura fica alocada fisicamente no banco de dados e é a principal responsável por tornar possível refazermos uma determinada transação que possa ter sofrido algum tipo de indisponibilidade causado pelo ambiente.
No processo realizado para os arquivos de redo, antes mesmo de serem gravados em disco, são geradas entradas no Buffer de Redo, ou Redo Log Buffer, só depois de realizado o comprometimento e/ou confirmação (commit) o Buffer é esvaziado permitindo assim novas estradas. Uma coisa muito importante sobre a utilização dos arquivos de redo pelo banco é que em caso de falhas, eles nos garantirão a recuperação até o ponto onde eles tenham gravado a informação.
Esse arquivo é uma cadeia contínua e cronológica de cada vetor de alteração (“instruções” para desfazer um DML de alteração – insert, update, delete). Um exemplo para melhor conhecimento e entendimento desses arquivos é na recuperação de uma base após um problema que necessite “voltar” o backup. Para que não haja perda de trabalho até o momento do erro, os arquivos de redo log podem ser aplicados ao backup para refazer o trabalho, adiantando-os no tempo até o momento em que o dano ocorreu.
Archive
Redo log file arquivado, ou archive.
Um SGBD garante que sua instância nunca fique corrompida, por meio dos redo log files, porém para garantir que não haja perda de dados após uma falha, é necessário ter um registro de todas as alterações aplicadas ao banco de dados desde o último backup. Por default, um banco de dados é criado em modo NOARCHIVELOG, o que significa que os redo log files são sobrescritos sem que tenha ocorrido o arquivamento dos seus dados. Quando alteramos o banco para o modo ARCHIVELOG, o SGBD torna impossível a perda de dados (desde que os archives gerados após o último backup estejam disponíveis). Nesse modo, um novo processo de background (na verdade são quatro processos por default) será iniciado automaticamente: o Archiver (ARCn).
É importante saber que a transição do modo NOARCHIVELOG para ARCHIVELOG (ou o contrário) só pode ser feita enquanto o banco está no modo mount após um shutdown e deve ser feito por um usuário com privilégio SYSDBA. Também é necessário fazer a configuração nos parâmetros de inicialização que controlam os nomes e os locais dos archives.
Tolerância a falhas com arquivos
Processamento de transações, concorrência e bloqueios
Monitorar as transações, configurar as concorrências e administrar os bloqueios
Transações
Representa um conjunto de várias operação em um BD, podendo ser visto pelo usuário como uma única unidade.
Transação também é uma unidade lógica de processamento de operações sobre um banco de dados. Ela é formada por uma sequência de operações que precisam ser executadas integralmente para garantir a consistência e a precisão.
Geralmente, uma transação consiste de uma das seguintes instruções:
· uma ou mais instruções DML (Data Manipulation Language);
· uma instrução DDL (Data Definition Language);
· uma instrução DCL (Data Control Language).
Uma transação começa a partir da execução da 1ª instrução SQL e termina com um dos seguintes eventos:
- COMMIT ou ROLLBACK;
- instrução DDL ou DCL (commit automático);
- o usuário desconecta do banco de dados (commit automático);
-  o sistema falha (rollback automático).
Quando uma transação termina, o próximo comando SQL inicia automaticamente a próxima transação.
Como acontecem as transações
Fonte: Elaborado pelo professor conteudista.
Exemplos:
INSERT INTO Departamento (ID_Depto, NomeDepto, ID_Gerente) VALUES (10, 'Marketing', 3);
UPDATE Funcionario SET salario = salario * 1.05 WHERE ID_Depto = 5;
COMMIT;
DELETE FROM Funcionario;
ROLLBACK;
No exemplo, o departamento 10 é inserido, os salários dos funcionários do departamento 5 são atualizados, mas nenhum funcionário é excluído.
INSERT INTO Departamento (ID_Depto, NomeDepto, ID_Gerente) VALUES (11, 'RH', 2);
SAVEPOINT ponto1;
DELETE FROM Funcionario;
ROLLBACK TO SAVEPOINT ponto1;
UPDATE Funcionario SET salario = salario * 1.05 WHERE ID_Depto = 5;
COMMIT;
No exemplo, o departamento 11 é inserido, os salários dos funcionários do departamento 5 são atualizados, mas nenhum funcionário é excluído.
Se uma única instrução DML falhar durante a execução, será feito rollback somente dessa instrução. Todas as outras alterações são mantidas. O usuário deve finalizar as transações explicitamente usando uma instrução COMMIT ou ROLLBACK.
Exemplo:
A transferência de fundos de uma conta corrente pra uma conta poupança é uma operação única do ponto de vista do cliente, porém, dentro do sistema de banco de dados, ela envolve várias operações.
É essencial que todo o conjunto de operações seja concluído, ou que, no caso de uma falha, nenhuma delas ocorra. Essas operações, que formam uma única unidade lógica de trabalho são chamadas de transações. 
Diagrama de estados de transação
Um SGBD precisa:
· Garantir que a execução da transação seja completa;
· Administrar a execução simultânea de várias transações evitando inconsistências;
As operações de acesso ao BD que uma transação pode fazer são:
· read(x):que transfere o item de dados x do BD para um buffer local alocado à transação que executou a operação de read. O valor de x é colocado dentro de uma variável de programa.
· write(x): que transfere o item de dados x do buffer local da transação que executou o write de volta para o BD. O valor da variável de programa é passado para o item de dado no BD.
Executar read(x):
Encontrar o endereço do bloco de disco que contém x;
Copiar este bloco de disco para dentro do buffer/memória principal, se ele já não estiver lá; Copiar o item x do buffer para a variável de programa.
Executar write(x):
Encontrar o endereço do bloco de disco que contém x;
Copiar o bloco de disco para a memória principal se ele já não estiver lá;
Copiar o item x da variável de programa x para a localização correta no buffer;
Copiar o bloco alterado do buffer de volta para o disco (imediatamente ou mais tarde).
Exemplo:
Seja T1 uma transação que transfere 50 reais da conta A para a conta B. Essa transação pode ser definida como:
T1: read(A);
A := A - 50;
Outro Exemplo
write(A);
read(B); B := B + 50;
write(B);
As propriedades (ACID) de uma transação são:
Atomicidade: uma transação é uma unidade atômica de processamento; é realizada integralmente ou não é realizada.
Consistência: uma transação é consistente se levar o banco de dados de um estado consistente para outro estado também consistente.
Isolamento: a execução de uma transação não deve sofrer interferência de quaisquer outras transações que estejam sendo executadas concorrentemente.
Durabilidade (ou persistência): as alterações aplicadas ao banco de dados, por meio de uma transação confirmada, devem persistir no banco de dados, não sendo perdidas por nenhuma falha.
Concorrência
Permitir que múltiplas transações concorram na atualização de dados traz diversas complicações em relação à consistência desses dados.
Razões para permitir a concorrência:
Uma transação consiste em diversos passos. Alguns envolvem atividades de I/O, outras atividades de CPU. A CPU e os discos podem operar em paralelo. Logo, a atividade de I/O pode ser feita em paralelo com o processamento na CPU.
Enquanto uma leitura ou escrita é solicitada por uma transação que está em desenvolvimento em um disco, outra transação pode ser processada na CPU, e outro disco pode estar executando uma leitura ou escrita solicitada por uma terceira transação.
 Assim aumenta-se o rendimento do sistema, ou seja, o número de transações que podem ser executadas em um determinado tempo. Pode haver uma mistura de transações em execução simultânea no sistema, algumas curtas e outras longas. Se a execução das transações for sequencial, uma transação curta pode ser obrigada a esperar até que uma transação longa precedente se complete. Com a concorrência reduz-se o tempo médio de resposta, ou seja, o tempo médio para uma transação se r concluída após sua submissão.
Controle de concorrência
Fonte: Internet - http://pt.slideshare.net/natanaelsimoes/banco-de-dados-sistemas-de-gerenciamento-de-banco-de-dados
Exemplo:
Sejam T 1 e T 2 duas transações que transferem fundos de uma conta para outra. A transação T 1 transfere 50 dólares da conta A para a conta B. A transação T 2 transfere 10 por cento do saldo da conta A para a conta B.
	T1 :
read(A);
A := A – 50;
read(B);
B := B + 50;
write(B);
	T2:
read(A);
temp := A * 0,1;
A := A – temp;
write(A); 
read(B);
 B := B + temp;
write(B);
 
 
Execução Sequencial 
 
Execução sequêncial
Fonte:
Execução Concorrente
Execução concorrente
Problemas na Concorrência
Problema de alterações perdidas;
Ocorre quando duas transações que acessam o mesmo item de BD possuem suas operações intercaladas de uma maneira que o valor de algum item de dado fique incorreto.
Problema de alteração temporária;
Ocorre quando uma transação altera um item de dados e depois ela falha por alguma razão. O item de dado é acessado por outra transação antes que o valor original seja estabelecido.
Problema do resumo incorreto.
Se uma transação está calculando uma função agregada com um conjunto de tuplas e outras transações estão alterando algumas destas tuplas, a função agregada pode calcular alguns valores antes deles serem alterados e outros depois de serem alterados.
Bloqueios
Bloqueios são usados como um meio de sincronizar o acesso aos itens do banco de dados por transações concorrentes.
Um bloqueio consiste em uma variável associada a um item de dado, que descreve o status do item em relação a possíveis operações que podem ser aplicadas ao mesmo. Em geral, existe um bloqueio para cada item de dado no banco de dados. • Duas técnicas de bloqueio são:
- bloqueio binário;
- bloqueio múltiplo.
Um bloqueio binário possui dois estados: bloqueado (locked); desbloqueado (unlocked).
As operações necessárias são: lock_item(X): bloqueia o item X; unlock_item(X): desbloqueia o item X.
O bloqueio binário impõe a exclusão mútua no item de dado. Se uma operação de bloqueio ou desbloqueio de X for iniciada, nenhum entrelaçamento é permitido até que a operação em questão termine ou a transação espere. O comando de espera coloca a transação em uma fila de espera pelo item X até que o mesmo seja desbloqueado.
Bloqueio
Fonte: Elaborado pelo professor conteudista.
Algoritmos de bloqueio e desbloqueio do item X:
lock_item(X):
B: se LOCK(X) = 0 então (* item desbloqueado *)
LOCK(X) ← 1 (* bloquear o item *)
senão início
esperar até (LOCK(X) = 0 e o gerenciador de bloqueio despertar a transação);
goto B;
fim;
unlock_item(X):
LOCK(X) ← 0; (* desbloquear o item *)
se alguma transação estiver esperando então despertar uma das transações em espera;
Para que a técnica de bloqueio binário possa ser usada, uma transação T deve obedecer às seguintes regras:
T deve emitir um lock_item(X) antes que qualquer read_item(X) ou write_item(X) seja executado;
T deve emitir um unlock_item(X) depois que todos os read_item(X) e write_item(X) tenham sido completados em T;
T não poderá emitir lock_item(X) se X estiver bloqueado por T;
T poderá emitir um unlock_item(X) apenas se tiver bloqueado X.
O bloqueio binário é o mecanismo mais simples e mais restrito de controle de concorrência. A implementação requer uma tabela de bloqueios () e uma fila de espera.
Considere as seguintes transações:
Bloqueio binário
Um esquema de bloqueio múltiplo (read/write ou compartilhado/exclusivo) permite que um item de dado seja acessado por mais de uma transação para leitura.
As operações necessárias são: read_lock(X): bloqueia o item X para leitura, permitindo que outras transações leiam o item X (bloqueio compartilhado);
write_lock(X): bloqueia o item X para gravação, mantendo o bloqueio sobre o item X (bloqueio exclusivo);  unlock(X): desbloqueia o item X.
A implementação do bloqueio múltiplo requer uma tabela de bloqueios () e uma fila de espera.
Algoritmos de bloqueio e desbloqueio do item X:
read_lock(X):
B: se LOCK(X) = "unlocked" então início (* item desbloqueado *)
LOCK(X) ← "read-locked"; (* bloquear o item p/ leitura *)
num_de_leituras(X) ← 1;
 fim
senão se LOCK(X) = "read-locked" então (* bloqueado p/ leitura *)
num_de_leituras(X) ← num_de_leituras(X) + 1;
senão início
esperar até (LOCK(X) = "unlocked" e o gerenciador de bloqueio despertar a transação);
goto B;
fim;
Para que a técnica de bloqueio múltiplo possa ser usada, uma transação T deve obedecer às seguintes regras:
T deve emitir um read_lock(X) ou write_lock(X) antes que qualquer read_item(X) seja executado em T;
T deve emitir um write_lock(X) antes que qualquer write_item(X) seja executado em T;
T deve emitir um unlock(X) depois que todos os read_item(X) e write_item(X) tenham sido executados em T;
T não emitirá nenhum read_lock(X) ou write_lock(X) se X já estiver bloqueado por T (de forma compartilhada ou exclusiva);
T poderá emitir um unlock(X) apenas se tiver bloqueado X (de forma compartilhada ou exclusiva).
Considere as seguintes transações:
Bloqueio multiplo
Componentes de um SGBD - Processador de consultas
Conhecer como funciona o processador de consultas
Um sistema de banco de dados é dividido em módulosque tratam de cada uma das responsabilidades do sistema geral. Na maioria dos casos, o sistema operacional do computador fornece apenas os serviços mais básicos e o sistema de banco de dados precisa ser construído sobre essa base. Portanto, o projeto do sistema de banco de dados precisa incluir considerações sobre a interface entre o sistema de banco de dados e o sistema operacional.
Um dos componentes funcionais de um sistema de banco de dados é o:
Processador de consultas: ele traduz os comandos em uma linguagem de consulta para instruções de baixo nível que o gerenciador do banco de dados pode interpretar. Além disso, o processador de consultas tenta transformar uma requisição do usuário em uma forma compatível e mais eficiente com respeito ao banco de dados, encontrando uma boa estratégia para executar a consulta.
Consultas em SQL
É responsável por transformar uma consulta ou modificação solicitados pelo  usuário em uma sequência de operações a serem executadas sobre os dados de uma base de dados. O processador de consultas é responsável por:
· executar consultas
· modificar os dados da base de dados (inserir, remover, modificar) ou metadados (num SGBD relacional inclui nome das relações, nomes dos atributos, tipos de atributos)
· fazer um  planejamento (query plan) para obter a melhor maneira de executar uma consulta (ex: usar índice, reordenar as operações, etc)
 
Etapas de processamento
Esquema do processador de consultas
Tradução >>
· análise léxica: cláusulas SQL e nomes válidos
· análise sintática: validação da gramática
·  análise semântica: nomes usados de acordo com a estrutura do esquema
· conversão para uma árvore algébrica da consulta
Transformação >>
· definição de uma árvore de consulta equivalente: processa de forma mais  eficiente também chamada de  Otimização Algébrica
Definição de plano de execução >>
· análise de alternativas de definição de estratégias de acesso
·  escolha de algoritmos para implementação de operações
· existência de índices
· estimativas sobre os dados (tamanho de tabelas, seletividade, ...)
Árvore (Algébrica) da Consulta
Estrutura que representa o mapeamento da consulta para a álgebra relacional uma expressão da álgebra relacional “estendida” pode indicar alguma computação (função agregação, atributo calculado, ...)
· nodos folha: relações (do BD ou resultados intermediários)
· nodos internos: operações da álgebra
Processamento da árvore
Os nodos internos são executados quando seus operandos estão disponíveis e são substituídos pela relação resultante da execução e finaliza quando o nodo raiz é executado.
Exemplo de Árvore da Consulta
select m.CRM, m.nome, a.número, a.andar from Médicos m, Ambulatórios a
where m.especialidade = ‘ortopedia’ and a.andar = 2and m.número = a.número
Árvore de consulta
Exemplo de Árvore Equivalente
Árvore de consulta equivalente
Otimização Algébrica
Objetivo do passo de Transformação
entrada: árvore da consulta inicial
saída: árvore da consulta otimizada (pode manter a mesma árvore)
Base para construção da otimização
· regras de equivalência algébrica devem ser conhecidas pelo otimizador para que possam ser geradas transformações válidas
· algoritmo de otimização algébrica indica a ordem de aplicação das regras e de outros processamentos de otimização
Componentes de um SGBD - Sistema de armazenamento
Conhecer como funciona o sistema de armazenamento de um SGBD
Um Sistema Gerenciador de Banco de Dados é composto por um conjunto de programas cuja responsabilidade é de prover o  gerenciamento de uma base de dados. Seu objetivo é retirar da aplicação a responsabilidade de gerenciar o acesso, manipulação e organização dos dados. O SGBD disponibiliza uma interface para que os seus clientes possam  incluir, alterar ou consultar dados. Em bancos de dados relacionais a interface é constituída pelas APIs ou drivers do SGBD, que executam comandos na linguagem SQL.
Em tempos de comunicação digital, onde tudo pode ser compartilhado de um extremo a outro do planeta em segundos, a posse da informação tornou-se o ativo mais importante das empresas. Em alguns casos é mais valioso do que o patrimônio físico, como imóveis e veículos. É raro quando uma empresa consegue sobreviver no mercado competitivo e globalizado sem coletar e gerenciar as informações relativas ao seu negócio.
Isso demonstra a importância de se administrar o processo de armazenamento em um SGBD. Para isso dentro do SGBD pode-se controlar os recursos existentes  para um excelente trabalho com os dados.
Componente SGBD - Armazenamento
Gerenciador de Arquivos: Gerencia a alocação do espaço na armazenagem em disco e as estruturas de dados usadas para representar a informação;
Gerenciador do Banco de Dados: Fornece a interface entre os dados de baixo nível armazenados em disco e os programas aplicativos;
Processador de Consultas: Traduz comandos numa linguagem de consulta em instruções de baixo nível que o gerenciador do banco de dados pode interpretar.
Módulo de armazenamento
 Pré-compilador da DML: Converte comandos da DML embutidos em um aplicativo para chamadas de procedimento normal na linguagem hospedeira.
Compilador da DDL: Converte comandos DDL em um conjunto de tabelas contendo metadados (dados sobre dados).
Arquivos de dados: Armazenam os dados do banco de dados.
Dicionário de dados: Armazena metadados sobre a estrutura do banco de dados.
Índices: Fornecem acesso rápido aos itens de dados guardando determinados valores.
Módulo de armazenamento - DML, DDL
Componentes de um SGBD - Arquivo de dados, índices
Conhecer o trabalho com arquivos e índices de um SGBD
Todo o banco de dados tem, no mínimo, dois arquivos de sistema operacional: um arquivo de dados e um arquivo de log. Os arquivos de dados contêm dados e objetos como tabelas, índices, procedimentos armazenados e exibições. Os arquivos de log contêm as informações necessárias para recuperar todas as transações no banco de dados. Os arquivos de dados podem ser agrupados em grupos de arquivos para propósitos de alocação e administração.
	Arquivo
	Descrição
	Primário
	O arquivo de dados primário contém as informações de inicialização do banco de dados e aponta para os outros arquivos no banco de dados. Dados do usuário e objetos podem ser armazenados neste arquivo ou em arquivos de dados secundários. Todo banco de dados possui um arquivo de dados primário.
	Secundário
	Os arquivos de dados secundários são opcionais, definidos pelo usuário, e armazenam dados do usuário. Arquivos secundários podem ser usados para distribuir os dados entre os diversos discos, colocando cada arquivo em uma unidade de disco diferente. Além disso, caso um banco de dados exceda o tamanho máximo em um único arquivo será possível usar arquivos de dados secundários, assim, o banco de dados continuará a crescer.
	Log de Transações
	Os arquivos de log de transações armazenam as informações de log usadas para recuperar o banco de dados. Deve haver, no mínimo, um arquivo de log para cada banco de dados.
Esquema de um SGBD - Arquivos e Índices
Por exemplo, pode-se criar um simples banco de dados nomeado como Vendas que tenha um arquivo primário com todos os dados e objetos, e um arquivo de log que tenha as informações de log de transação. Como alternativa, pode-se criar um banco de dados mais complexo nomeado como Pedidos que tenha um arquivo primário e cinco arquivos secundários. Os dados e objetos no banco de dados distribuem-se pelos seis arquivos, e os quatro arquivos de log contêm as informações do log de transação. Por padrão, os dados e logs de transação são colocados na mesma unidade e caminho. Isto é feito para controlar os sistemas de um único disco. Porém, isto não é o ideal para ambientes de produção. Recomenda-se que coloque os dados e arquivos de log em discos separados.
Grupos de arquivos
Todo banco de dados possui um grupo de arquivo primário. Este grupo de arquivo contém o arquivo de dados primário e qualquer um dos arquivos secundários que não foram colocados em outros grupos de arquivos. Grupos de arquivos definidos pelousuário podem ser criados para agrupar os arquivos de dados para fins administrativos, de alocação de dados e de posicionamento.
Por exemplo, três arquivos, Data1, Data2 e Data3, podem ser criados em três unidades de disco, respectivamente, e atribuídos ao grupo de arquivos fgroup1. Uma tabela pode ser criada especificamente no grupo de arquivos fgroup1. As consultas para obter dados da tabela serão distribuídas pelos três discos; isso melhorará o desempenho. A mesma melhora no desenvolvimento pode acontecer, usando um único arquivo criado em um conjunto distribuído RAID (redundant array of independent disks). Porém, arquivos e grupos de arquivos permitem que novos arquivos sejam facilmente adicionados aos novos discos.
	Grupo de arquivos
	Descrição
	Primário
	O grupo de arquivos que contém o arquivo primário. Todas as tabelas do sistema são alocadas no grupo de arquivos primário.
	Definido pelo usuário
	Qualquer grupo de arquivos que seja criado especificamente pelo usuário quando o usuário cria primeiro ou modifica depois o banco de dados.
Grupo de arquivos
Grupo de arquivos padrão
Quando objetos são criados no banco de dados sem especificar a qual grupo de arquivos eles pertencem, os objetos são atribuídos ao grupo de arquivos padrão. A qualquer hora, um grupo de arquivos é designado como o grupo de arquivos padrão. Os arquivos no grupo de arquivos padrão devem ser grandes o suficiente para armazenar qualquer objeto novo alocado a outros grupos de arquivo.
O grupo de arquivos PRIMÁRIO é o grupo de arquivos padrão, a menos que seja alterado usando a instrução ALTER DATABASE. A alocação para os objetos de sistema e de tabelas permanece no grupo de arquivos PRIMÁRIO, e não no novo grupo de arquivos padrão.
Índices
Uma atividade comumente realizada por administradores de sistemas de bancos de dados para acelerar o desempenho de consultas submetidas a um SGBD relacional é a seleção de índices sobre as tabelas presentes na base de dados. Essa atividade é complexa e envolve diversos fatores como, por exemplo: obtenção da carga de trabalho e a escolha de quais tabelas e colunas devem ser indexadas.
Um índice é uma organização de dados que permite acelerar o processamento de consultas. Uma chave de um índice é uma sequência de atributos e são feitos mapeamentos entre os valores desta sequência e seus registros correspondentes.
O uso de índices pode trazer grandes melhorias para o desempenho do banco de dados. 
Fonte:
Como funciona
Os registros são armazenados em páginas de dados, páginas estas que compõem o que é chamado de pilha, que por sua vez é uma coleção de páginas de dados que contém os registros de uma tabela. Cada página de dados tem seu tamanho definido em até 8 Kb, apresenta um cabeçalho, também conhecido como header, que contém arquivos de links com outras páginas e identificadores (hash) que ocupam a nona parte do seu tamanho total (8 Kb) e o resto de sua área é destinada aos dados. Quando são formados grupos de oito páginas (64 Kb), chamamos este conjunto de,Usando índices
Busca por índice
Arquitetura de Índice
Existem três tipos de índices:
Índices de agrupamento ou ordenados:Quando um índice sem agrupamento é criado sobre a pilha, o SQL Server usa os identificadores de registros das páginas de índice que indicam os registros das páginas de dados.
Quando um índice sem agrupamento é criado sobre uma tabela com um índice de agrupamento, pode ser usada uma chave de agrupamento nas páginas de índice que indicam o índice de agrupamento. A chave de agrupamento armazena informações sobre a localização dos dados (headers em forma de hash).
Componentes de um SGBD - Catálogo
Conhecer a função do catálogo no SGBD
Os catálogos do sistema são os locais onde os sistemas gerenciadores de banco de dados relacionais armazenam os metadados do esquema, tais como informações sobre tabelas e colunas, e informações de controle internas. Normalmente, os catálogos do sistema não devem ser modificados manualmente, sempre existe um comando SQL para fazê-lo (Por exemplo, CREATE DATABASE insere uma linha no catálogo database — e cria realmente o banco de dados no disco). Existem exceções para algumas operações muito particulares, como adicionar método de acesso de índice.
Eles são, em sua maioria, copiados do modelo do banco de dados durante a criação desse banco. O catálogo é usado tanto pelo SGBD como pelos usuários do banco de dados que precisam de informações sobre a estrutura desse banco. Um pacote de software de propósito geral não está determinado para uma aplicação específica, portanto, para sua utilização será necessário acessar o catálogo para conhecer a estrutura dos arquivos no banco de dados, como o tipo e o formato dos dados que o programa acessará, por exemplo a utilização do comando que mostra a estrutura de uma determinada tabela em um SGBD específico. Algumas referências tratam o termo catálogo de banco de dados como metadados de banco de dados. 
Exemplo de catálogo
Exemplos de catálogos em SGBDs
Catálogo no DB2
 O catálogo no DB2 é um banco de dados de sistema que contém informações (descritores) relativas a diversos objetos que são de interesse do próprio sistema.
 Tabelas base, visões, índices, banco de dados, planos de aplicação, direitos de acesso entre outros são exemplos desses objetos. Uma vantagem significativa de um sistema relacional como o DB2 é que o catálogo num sistema propriamente dito consiste de relações (ou tabelas de sistema).
Algumas tabelas de catálogo do DB2 são: SYSTABLES, SYSCOLUMNS, SYSINDEXES.
SYSTABLES: contém uma linha para cada tabela (base ou visão) em todo o sistema. Para cada uma dessas tabelas ela fornece informações como: nome de tabela (NAME), nome de usuário que o criou (CREATOR) e quantidade de suas colunas (COLCOUNT).
SYSCOLUMNS: contém uma linha para cada coluna de cada tabela em todo o sistema. Para cada uma dessas colunas, uma linha fornece, por exemplo, nome da coluna (NAME), nome da tabela da qual a coluna faz parte (TBNAME) e tipo de dados da coluna (COLTYPE).
SYSINDEXES: contém uma linha para cada índice no sistema. Para cada um desses índices ela fornece: nome do índice (NAME), nome da tabela indexada (TBNAME), nome de usuário que criou o índice (CREATOR) e assim por diante.
Catálogo DB2
Catálogo no MySQL
 Em um banco de dados institucional, o INFORMATION_SCHEMA é visto somente pelo administrador do banco de dados, pois ali estão armazenadas todas as informações referentes aos bancos de dados criados.
Ele é o banco de informações, o local em que se armazena informações sobre todos os outros bancos que o servidor MySQL mantém. Dentro do INFORMATION_SCHEMA existem várias tabelas somente para leitura. Elas são visões e não são tabelas de base, portanto, não existem arquivos a elas associados.
O INFORMATION_SCHEMA fornece acesso aos metadados do banco de dados, tais como o nome de um banco de dados ou tabela, o tipo de dados de uma coluna e privilégios de acesso. É possível selecionar o INFORMATION_SCHEMA como o banco de dados padrão com a instrução USE, mas com ele só é possível ler o conteúdo das tabelas. Não é possível inserir, atualizar ou apagar dados a partir dele.
Algumas tabelas do INFORMATION_SCHEMA são descritas a seguir.
SCHEMATA: Um esquema (schema) descreve um banco de dados, portanto a tabela SCHEMATA informa sobre um banco de dados;
TABLES:  tabela TABLES informa sobre as tabelas criadas nos bancos de dados;
COLUMNS: a tabela COLUMNS informa sobre colunas e tabelas de todos os bancos de dados;
STATISTICS: a tabela STATISTICS informa sobre tabela de índices;
USER_PRIVILEGES: a tabela USER_PRIVILEGES informa sobre privilégios globais, cujo acesso é obtido a partir da permissão da tabela mysql.user;
SCHEMA_PRIVILEGES: a tabela SCHEMA_PRIVILEGES informa sobre o esquema de privilégios do banco de dados obtido a partir da permissão da tabela mysql.user.
Catálogo MySql
Catálogo no Oracle
 Os catálogos no Oracle são informações dos objetos do banco de dados Oracle como pode ser visto parcialmente a seguir:
 ALL_TABLES: contém todas as tabelasdo banco de dados atual que são acessíveis ao usuário;
 ALL_TAB_COLUMNS: contém todas as colunas no banco de dados que são acessíveis ao usuário;
 ALL_ARGUMENTS: contém os argumentos de funções e procedimentos que são acessíveis ao usuário;
 ALL_ERRORS: contém descrições de erros sobre todos os objetos armazenados - visões, procedimentos, funções, pacotes e corpos de pacotes - que são acessíveis ao usuário;
ALL_OBJECT_SIZE: incluído para fins de compatibilidade a versões anteriores do Oracle 5;
ALL_PROCEDURES: (a partir do Oracle 9 em diante) contém todas as funções e os procedimentos (juntamente com as propriedades associadas) que são acessíveis ao usuário atual;
ALL_SOURCE: descreve o texto (isto é, o PL/SQL), fonte de objetos armazenados acessíveis ao usuário.
Catálogo Oracle
Utilitários de uma SGBD - Carga (loading), Cópia de segurança (backup)
Conhecer a carga de dados e o backup em SGBD
Utilitários são programas projetados para auxiliar o DBA com diversas tarefas administrativas, alguns programas utilitários operam no nível externo do sistema e, portanto, são na verdade apenas aplicações de uso especial outros podem nem mesmo ser fornecidos pelo fabricante do SGBD, mas sim por terceiros. Existem, porém utilitários operam diretamente no nível interno e, desse modo, devem ser oferecidos pelo fornecedor do SGBD.
Exemplos dos tipos de utilitários que costumam ser necessários na prática:
· Rotinas de carga, a fim de criar a versão inicial do banco de dados a partir de um ou mais arquivos do sistema operacional.
· Rotinas de descarga/recarga (ou dump/restore), a fim de descarregar o banco de dados, ou partes dele, para o meio de armazenamento de backup e recarregar dados dessas cópias de backup.
· Rotinas de reorganização, a fim de arrumar novamente os dados no banco de dados armazenado por vários motivos (em geral, relacionadas com o desempenho) - por exemplo, para clusterizar dados de algum modo particular no disco, ou para retomar o espaço ocupado por dados já logicamente excluídos.
· Rotinas estatísticas, a fim de calcular diversas estatísticas de desempenho, tais como tamanhos de arquivos e distribuição de valores, contagens de E/S e assim por diante.
· Rotinas de análise, a fim de analisar as estatísticas mencionadas antes.
Utilitários do SGBD
Naturalmente, essa lista representa apenas uma pequena amostra das funções em geral oferecidas pelos utilitários; existem várias outras possibilidades.
Carga no banco de dados
Uma vez que uma empresa esteja comprometida com um sistema de banco de dados, ela se torna dependente de modo crítico da operação desse sistema com sucesso. Em caso de danos a qualquer parte do banco de dados - provocados por erro humano, ou por uma falha de hardware ou ainda do sistema operacional é essencial que haja um processo com capacidade de reparar os dados em questão com um mínimo de demora e com o menor efeito possível sobre o restante do sistema. Por exemplo, em condições ideais, a disponibilidade dos dados que não tenham sido danificados não deve ser afetada. O DBA tem de definir e implementar um esquema apropriado de controle de danos, em geral envolvendo (a) descarga ou "dumping" periódico do banco de dados para o meio de armazenamento de backup e (b) recarga ou "restauração" do banco de dados quando necessário, a partir do "dump" mais recente.
A propósito esta necessidade de reparo rápido dos dados é a razão pela qual seria uma boa ideia espalhar a coleção total de dados por vários bancos de dados, em vez de manter tudo em um único lugar; o banco de dados individual poderia muito bem formar a unidade para finalidades de descarga e recarga. 
Carga de dados
Fonte: Elaborado pelo professor conteudista.
Backup no banco de dados
O backup do banco de dados é de extrema importância para que se possa manter a integridade dos dados caso haja uma falha do sistema, hardware ou até mesmo para corrigir eventuais falhas de usuários, como por exemplo, a remoção acidental de um banco de dados. Para isto, é importante a adoção de uma política consistente de backup (diariamente).Nos SGBD existem tipos diferentes de backup com pro exemplo o binário do banco, isto é, uma cópia da estrutura de arquivos e diretórios que constituem os seus dos bancos de dados e tabelas é armazenada para fins de segurança. Além disto, pode-se optar pelo backup dos dados, onde serão armazenados os dados em formato texto ou em forma de comandos SQL.
Ao ser realizado um procedimento de backup é criada uma imagem dos seus dados no momento da execução da rotina de backup. A função desta cópia de segurança é ser usada no momento da necessidade de resolver os problemas que poderão vir a acontecer nesta base de dados, assim será possível utilizar o último backup retornando só os dados para a situação em que o banco se encontrava no momento desta criação da cópia.
O que acontece com os dados alterados ou inseridos entre o backup e a falha?
Em alguns SGBDs pode-se habilitar um log binário de alterações (opção log-bin no arquivo de configuração), que armazenam todos os comandos que modificam a estrutura do banco de dados, sendo que estes podem ser utilizados para recuperar os dados não contidos no backup. Os logs são criados com a extensão que indica o número de sequência do log, que é incrementado sempre que um novo log é criado.
Uma forma de backup é a baseada na cópia dos arquivos do banco de dados, ela pode ser feita manualmente com os comandos de cópia do sistema operacional (SO) ou utilizando ferramentas de backup do próprio SO. Vale ressaltar que para garantir uma cópia consistente destes arquivos é preciso garantir que não haverá escritas na base de dados durante a execução da rotina de backup. Esta condição pode ser garantida através de uma parada no gerenciador de banco de dados (SGBD) ou por meio de um bloqueio das tabelas permitindo apenas a leituras dos dados (lock) durante o backup.
O principal problema do backup com cópia de arquivos é o fato de que caso existam arquivos corrompidos o seu backup herdará esta estrutura inconsistente, e possivelmente acarretará problemas durante a restauração da base de dados através deste backup. Para contornar esta situação é melhor que se faça uma cópia apenas dos dados e não dos arquivos.
Backup em um SGBD
Fonte: Elaborado pelo professor conteudista.
Utilitários de um SGBD - Monitoramento do desempenho
Identificar os processos de desempenho de um SGBD
Em tempos atuais de armazenamento de grande volume de dados, o trabalho do administrador de banco de dados fica cada vez mais complexo. Estes DBAs sempre tiveram de lidar com tarefas complexas em meio a prioridades de mudança, as dificuldades têm sido maiores nos últimos anos e o trabalho do DBA nunca foi tão desafiador. Alguns dos fatores que afetam os DBAs incluem:
Mais dados – O crescimento de dados tem sido enorme, nível de terabytes e até mesmo petabytes. Com isso a demanda é interminável por maior armazenamento, aumentando a complexidade de tarefas comuns de gerenciamento de banco de dados, tais como back-ups, planejamento de capacidade e conformidade com acordos de nível de serviço.
Mais bancos de dados – Gerenciamento de um banco de dados até dezenas ou mesmo centenas.
Consolidação / Virtualização – A pressa em se consolidar e virtualizar data centers criou novos tipos de problemas em termos de administração de banco de dados, abrangendo desde o planejamento da capacidade de servidores ao monitoramento do desempenho e a resolução de problemas, entre outros.
Complexidade adicional – Apesar de os fatores acima aumentarem tremendamente a complexidade do dia-a-dia dos DBAs, os fornecedores têm reagido com bancos de dados cada vez mais "autogerenciados" ou "autoconfigurados".
Carência de pessoal – Administradores de banco de dados experientes sempre foram difíceis de encontrar. Mesmo com cada vez mais liberdade de contratação, muitas empresas não conseguem achar o talento ou o conhecimento especializado de que precisam para gerenciar seus bancos de dados prioritários. 
Monitoramento de desempenho
Monitoramento/Gerenciamentode desempenho:
Cada profissional deseja que seus bancos de dados rodem o mais rápido possível. O mesmo pode ser dito para cada pessoa que utiliza um sistema que se conecta a esses bancos de dados: eles desejam que suas consultas e processos tenham o tempo de resposta mais curto possível. Mais uma vez, a situação é complicada quando você possui mais de uma plataforma de banco de dados. As variáveis e as soluções são diferentes de uma plataforma para outra.
Como resultado, deve ser estabelecido um plano neutro em termos de plataforma que se aplique a todos os mecanismos de banco de dados que serão gerenciados.
O primeiro passo é definir os diferentes métodos de análise que serão usados em todas as plataformas e, em seguida, aplicar um conjunto de diagnósticos e ações que podem ser usados para cada plataforma conforme cada método. Esses métodos de análise incluem:
· Análise dos obstáculos de desempenho e tempos de resposta
· Análise da carga de trabalho
· Análise de coeficientes
ANÁLISE DOS OBSTÁCULOS DE DESEMPENHO E TEMPOS DE RESPOSTA
 
Independente da plataforma, quando um banco de dados está ativo e disponível, cada processo conectado pertence a uma dentre duas situações: ocupado trabalhando ou aguardando para ser utilizado. Um processo em espera pode não significar nada, mas pode também indicar a existência de um gargalo de desempenho.
Esta análise permite determinar se sua presença em um banco de dados contribui com um problema de desempenho, pois ajuda o profissional a rastrear onde o banco de dados está utilizando seu tempo. Se um processo ou uma atividade pesada de leitura de tabelas estiver atrasando o desempenho de um banco de dados, o DBA poderá utilizar uma análise de obstáculos de desempenho para encontrar a causa. Assim que uma ou mais causas em potencial forem identificadas, ele poderá investigar em detalhes as sessões e objetos que estão causando o problema. Esse método é a estratégia preferida dos analistas de alto desempenho do setor. Nesse caso, quase todos os fornecedores de banco de dados desenvolveram seus mecanismos para que forneçam indicadores que possam ser usados de forma inteligente para analisar gargalos de desempenho e tempos de resposta. 
Análise de Obstáculo e tempo
ANÁLISE DA CARGA DE TRABALHO
 A análise da carga de trabalho envolve a investigação de duas áreas cruciais do desempenho de um banco de dados:
· Atividade e consumo de recursos da sessão
· Análise da execução em SQL
 Quando o desempenho de um banco de dados diminui subitamente, não é raro encontrar uma ou duas sessões que estejam gerando a maior parte da carga de trabalho. A questão é o equilíbrio do sistema. Em um sistema bem-equilibrado, nenhuma sessão isolada deveria consumir a maior parte dos recursos por um período extenso, com exceção de processos de trabalhos em lote que rodam com segurança em horários fora de pico. Se sessões individuais estão utilizando a maioria dos recursos do sistema, o DBA deve examinar cada sessão problemática em detalhes para revelar sua atividade. Normalmente, isso pode ser realizado facilmente ao se visualizar os metadados da sessão emparelhados com dados estatísticos do consumo de recursos e execução. Alguns mecanismos de banco de dados fornecem bastante detalhes sobre as atividades atuais e anteriores de uma sessão. Compreender os padrões de execução em SQL atuais e anteriores permite ao analista de banco de dados obter o segundo conjunto de pontos de dados necessário para se realizar uma análise apropriada da carga de trabalho.
A otimização de código em SQL é o segundo melhor método disponível para se impulsionar o desempenho de um banco de dados, sendo design físico adequado o melhor. Qual conjunto de indicadores você deveria utilizar, entretanto, para comparar um SQL “bom” com um SQL “ruim”?
Naturalmente, fatores gerais como tempo decorrido, tempo de CPU e atividade de E/S exercem uma certa influência. Outros fatores mais sutis, porém, podem fazer a diferença, tais como o número de vezes que uma declaração é executada ou se ordenamentos são realizados na memória ou no disco. É aí que a análise de SQL se torna mais uma arte do que uma ciência exata. Todos os fornecedores de bancos de dados oferecem uma janela para análise de SQL.
Análise de carga de Trabalho
ANÁLISE DE COEFICIENTES
A análise baseada em coeficientes tem sido aplicada há vários anos e costumava ser a única técnica que os administradores de bancos de dados utilizavam para diagnosticar a causa da queda de desempenho. Os DBAs têm grande familiaridade com as taxas de acertos no cache do buffer, no plano de procedimentos, no cache de dados e assim por diante. Muitos gurus na área de desempenho avisam que tais coeficientes já perderam a importância e a confiabilidade devido aos avanços na análise de gargalos de desempenho e tempo de resposta.
Análise de Coeficientes
Classificação dos SGBDs
Descrever os tipos de modelos de dados existentes
Um banco de dados é uma coleção organizada de dados utilizados para a finalidade de modelar algum tipo de organização ou processo organizacional. No momento que você está reunindo dados de alguma forma organizada para uma finalidade específica, você tem um banco de dados. Existem dois tipos de banco de dados encontrados na gestão de banco de dados, banco de dados operacionais e bancos de dados analíticos.
Bancos de dados operacional é a espinha dorsal de muitas empresas, organizações, e instituições em todo o mundo de hoje. Este tipo de banco de dados é usado principalmente em cenários de processamento de transações on-line (OLTP), ou seja, em situações onde há necessidade de se recolher, modificar e manter os dados em uma base diária. O tipo de dados armazenados em um banco de dados operacional é dinâmico, significando que ele muda constantemente e sempre reflete informações up-to-the-minute.
Organizações, tais como lojas de varejo, companhias de manufatura, hospitais e clínicas e editoras, usam bancos de dados operacionais, pois seus dados estão em um constante estado de fluxo. Em contraste, bancos de dados analíticos são usados principalmente em cenários de processamento analítico on-line (OLAP), onde há a necessidade de armazenar e controlar dados históricos com dependência de tempo.
Um banco de dados analítico é um recurso valioso quando há uma necessidade de acompanhar as tendências, visualizar dados estatísticos durante um longo período de tempo, e fazer projeções de negócios táticas ou estratégicas. Este tipo de banco de dados armazena dados estáticos, o que significa que os dados nunca (ou muito raramente) é modificado.
A informação recolhida a partir de um banco de dados analítico reflete dados em um ponto instantâneo no tempo. Laboratórios químicos, geológicos, empresas de marketing e análise são exemplos de organizações que usam bancos de dados analíticos.
Tipos de modelos de dados
Segundo a classificação temos:
Quanto ao modelo de dados adotado:
Relacionais, um banco de dados relacional armazena dados em relações, que o usuário entende como tabelas. Cada relação é composta de tuplas, ou registros e atributos, ou campos.
A ordem física dos registros ou campos em uma tabela é completamente irrelevante, e cada registro na tabela é identificada por um campo que contém um valor único. Estas são as duas características de um banco de dados relacional que permitem aos dados existirem independentemente da forma como ele está fisicamente armazenado no computador.
Como tal, um usuário não é obrigado a conhecer a localização física de um registro, a fim de recuperar seus dados. Isso é diferente dos modelos de banco de dados de rede e hierárquico, em que conhecer o layout das estruturas é crucial para a recuperação de dados. A relação entre um par de tabelas é estabelecido implicitamente através de valores correspondentes de um campo compartilhado.
Modelo Relacional
De rede, o banco de dados de rede foi, na sua maior parte, desenvolvido como uma tentativa para resolver alguns dos problemas da base de dados hierárquica. A estrutura de um banco de dados de rede está representadaem termos de nós e estruturas definidas.
Um nó representa uma coleção de registros e uma estrutura definida estabelece e representa um relacionamento em um banco de dados da rede. É uma construção transparente que se relaciona com um par de nós em conjunto usando um nó como um proprietário e outro nó como um membro.
A estrutura suporta um conjunto de relação um-para-muitos, o que significa que um registro no nó proprietário pode estar relacionado a um ou mais registros no nó do membro, mas um único registro no nó do membro está relacionado com apenas uma gravação no nó proprietário.
Além disso, um registro no nó membro não pode existir sem estar relacionado a um registro existente no nó proprietário. Por exemplo, um cliente deve ser atribuído a um agente, mas um agente com nenhum cliente ainda pode ser listado na base de dados. Uma vantagem que o banco de dados de rede fornece é um acesso rápido aos dados.
Ele também permite aos usuários criar consultas que são mais complexas do que aquelas criadas usando um banco de dados hierárquico. A principal desvantagem do banco de dados da rede é que o usuário tem de estar muito familiarizado com a estrutura do banco de dados, a fim de trabalhar com o conjunto de estruturas. Outra desvantagem é que não é fácil mudar a estrutura do banco de dados sem afetar os programas aplicativos que interagem com ele.
Você não pode mudar um conjunto de estrutura sem afetar os programas de aplicativos que usam essa estrutura para navegar pelos dados. Se você alterar um conjunto de estrutura, você também deve modificar todas as referências feitas a partir do programa de aplicação para essa estrutura. 
Modelo em rede
Hierárquicos, dados neste tipo de banco de dados estão hierarquicamente estruturados e é tipicamente diagramado como uma árvore invertida. Uma única tabela no banco de dados funciona como a "raiz" da árvore invertida e as outras tabelas atuam como os ramos que fluem a partir da raiz.
Uma relação num banco de dados hierárquico é representado pelo termo pai/filho. Neste tipo de relação, uma tabela pai pode ser associada com uma ou mais tabelas filho, mas uma única tabela filho pode ser associado com apenas uma tabela pai. Estas tabelas são explicitamente ligadas através de um ponteiro ou pela disposição física dos registros dentro das tabelas.
Um usuário acessa os dados dentro deste modelo, iniciando da tabela de raiz e trabalhando para baixo através da árvore para os dados de destino. Este método de acesso requer que o utilizador esteja muito familiarizado com a estrutura do banco de dados. Uma vantagem de usar um banco de dados hierárquico é que um usuário pode obter dados muito rapidamente, porque existem ligações explícitas entre as estruturas de tabelas.
Outra vantagem é que a integridade referencial é construída e automaticamente executada. Isso garante que um registro em uma tabela filho deve ser ligado a um registro existente em uma tabela pai, e que um registro excluído na tabela pai fará com que todos os registros associados na tabela filho para ser excluído. Em um banco de dados hierárquico ocorre problema quando um usuário precisa armazenar um registro em uma tabela filho que está alheio a qualquer registro em uma tabela pai. 
Modelo Hierárquico
Orientados a objetos, BDOOs podem ser utilizados como alternativa aos Bancos de Dados Relacionais para armazenar objetos compartilhados entre diferentes aplicações.
 Estes meios de armazenamento se tornaram conhecidos com o crescente uso de linguagens OO. BDOOs partem de uma premissa simples: o que se persiste são os objetos e, portanto, o seu “estado”, representado pelos atributos. Os atributos seriam equivalentes aos campos – ou colunas – de uma tabela.
Já as associações entre objetos (atributos que referenciam outros objetos) podem ser comparadas aos relacionamentos em SGBDRs, criados como restrições de integridade referencial (“chaves estrangeiras”). Assim, o correspondente a uma “tabela-filha” em um BDOO seria um atributo que tenha como valor outro objeto.
Uma vez armazenado um objeto em um meio físico, este pode ser recuperado para que as informações de seu estado sejam manipuladas. Este processo seria análogo à seleção de um registro em uma tabela, através de uma consulta.
Normalmente, BDOOs utilizam serialização como mecanismo de gravação e leitura de objetos, mas para o usuário isto ocorre de forma transparente, já que ele apenas necessita manipular o estado dos objetos em memória.
Assim como em SGBDRs, ferramentas de BDOOs também fornecem ambientes gráficos para administração dos bancos de dados, além de bibliotecas (APIs) para integração com aplicações. Estas APIs fornecem métodos de manipulação de objetos que representam as operações típicas de SQL.