modelo relacional normalizado-mrn
TRANSCRIPT
SISTEMA DE ENSINO PRESENCIAL CONECTADOTECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
AUTOR: NEI FÁBIO PIEDADE SANTOS
BANCO DE DADOS II
Itaberaba2010
NEI FABIO PIEDADE SANTOS
BANCO DE DADOS II
Trabalho apresentado ao Curso Tecnologia em Analise e desenvolvimento de Sistema da UNOPAR - Universidade Norte do Paraná, para a disciplina de BANCO DE DADOS II, Orientador: Roberto Yukio Nishimura
Itaberaba
2010
Indice
1.0.0-Introdução...................................................................................4
1.0.1-Modelo Relacional Normalizado-MRN .....................................5
1.0.2-Modelo
conceitual.......................................................................7
1.0.3-Modelo lógico..............................................................................7
1.0.4-Modelo físico...............................................................................8
1.0.5 -
SQL..............................................................................................8
1.1.0- Linguagem de definição de dados -DDL..............................10
1.1.1 - Declarações Create................................................................10
1.1.2- Declarações Drop....................................................................11
1.1.3 -Linguagem de manipulação de dados - DML.......................12
1.1.4-Linguagem de controle de dados – DCL................................12
1.1.5Processamento de transações de banco de Dados.............13
1.2.0-Propriedades ACID...................................................................15
1.2.1-Modelo de armazenamento de um banco de dados............. 18
1.2.2-Componentes do processamento de transações...19
1.2.3-Controle de Concorrência..........................................23
1.2.4-Escalonamento (schedules)......................................24
1.2.5-Escalonamento não serial.........................................25
1.3.0-Conclusão...................................................................28
1.3.1 Bibliografia..................................................................29
3
1.0.0- Introdução
Ao iniciar o trabalho será feito um apanhado geral, abordarei as fazes de um
projeto de banco de dados, conceito, utilização, funcionalidades e principais
objetivos alcançados com a implementação do Modelo Relacional Normalizado –
MRN, Padrão SQL, Processamento de Transações e Controle de Concorrência.
4
1.0.1- Modelo Relacional Normalizado-MRN
Introduziremos nosso trabalho fazendo as seguintes perguntas:
O que é o Modelo Relacional Normalizado –MRN?
Para que serve?
Qual a funcionalidade do MRN?
Quais são os objetivos?
Quais são os ganhos ao fazer a normalização do Banco de Dados?
O modelo relacional Normalizado é um modelo de dados, adequado a ser o
modelo subjacente de um Sistema Gerenciador de Banco de Dados (SGBD), que
se baseia no princípio em que todos os dados estão guardados em tabelas (ou,
matematicamente falando, relações). Toda sua definição é teórica e baseada na
lógica de predicados e na teoria dos conjuntos.
O conceito foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo
"Relational Model of Data for Large Shared Data Banks". Na verdade, o modelo
relacional foi o primeiro modelo de dados descrito teoricamente, os bancos de
dados já existentes passaram então a ser conhecidos como (modelo hierárquico,
modelo em rede ou Codasyl e modelo de listas invertidas).
O MRN apareceu devido às seguintes necessidades: aumentar a independência
dos dados nos sistemas operacionais de banco de dados; prover um conjunto de
funções apoiadas em álgebra relacional para armazenamento e recuperação de
dados; permitir processamento AD HOC(Em engenharia de software, a expressão
ad hoc é utilizada para designar ciclos completos de construção de softwares que
não foram devidamente projetado em razão da necessidade de atender a uma
demanda específica do usuário, ligada a prazo, qualidade ou custo). O modelo
relacional revelou-se ser o mais flexível e adequados ao solucionar os vários
problemas que se colocam no nível de concepção e implementação da Base de
Dados. A estrutura fundamental do modelo relacional é a relação (tabela). Uma
relação e construída por um ou mais atributos (campos) que traduzem o tipo de
5
dados a armazenar. Cada instancia do esquema (linha) e chamada de tupla
(registro). O modelo relaciona não tem caminhos pré-definidos para se fazer
acesso aos dados como nos modelos que o procedem. O modelo relacional
implementa estruturas de dados organizados em relações. Porem, para trabalhar
com essas tabelas, algumas restrições precisam ser impostas para evitar aspectos
indesejáveis, como: repetição de informação, incapacidade de representar parte
da informação e perda de informação. Essas restrições são: Integridade
referencial, chaves e integridades de junções de relações.
Tabela de Modelo Relacional normalizado – Cliente Conta corrente
O Modelo Entidade Relacionamento é a base para a criação de um banco de
dados.
Para realizarmos um projeto de banco de dados, podemos dividi-lo em três partes:
inicialmente o modelo conceitual, depois o modelo lógico, e finalmente o modelo
físico.
Realizar os três modelos é de extrema importância para que o analista de
sistemas compreenda a base de dados que ele vai criar. O administrador de
banco de dados (DBA) e o administrador de dados(AD) conseque separar muito
bem esses três modelos.
6
O primeiro passo e fazer o modelo conceitual; depois que ele já estiver completo
podemos transformá-lo em um modelo lógico, em que a estrutura fica mais
evidente para os analistas de sistemas e programadores.
Uma vez definido qual o SGBD a se utilizado , podemos passar esse modelo
lógico para o físico. Com o modelo físico concluído, já e possível escrever os
comandos necessários para a criação do esquema no banco de dados.
Hoje em dia existem ferramentas CASE que auxiliam o dia a dia dos analistas ,
DBAs e ADs.
1.0.2- Modelo conceitual
No modelo conceitual, iniciamos a analise sob o ponto de vista do nosso usuário,
o principal ciente para o sistema de banco de dados que será desenvolvido.
Aqui a modelagem e livre para identificara as entidades, os atributos e os
relacionamentos de acordo com a descrição textual narrativa do sistema.
Nesse aspecto, o nosso usuário deve olhar para o modelo e compreender
totalmente como os seus dados estão sendo modelados.
Aqui ainda nos nus preocupados com as características dos atributos, seu tipo de
dados ou mesmo suas restrições de mapeamento.
O nosso ponto de vista é a compreensão conceitual dos dados que serão
armazenados no banco de dados.
1.0.3- Modelo lógico
No modelo lógico, começamos a organizar melhor os dados que serão
armazenados e, identificamos os tipos dos atributos e algumas regras básicas
que podem ser implementadas dentro do próprio banco de dados (preenchimento
obrigatório do campo, valores default(valores esquecidos que deixaram de fazer
ou declarar), listas e valores possíveis).
Nesta fase, é interessante e altamente recomendadas que sejam aplicadas as
formas normais através do Modelo Relacional Normalizado, isso evita maiores
problemas na fase do modelo físico.
Quando estamos determinando os tipos de atributos, a relevância fica em alguns
tipos básicos, como numéricos, alfabéticos, alfanuméricos, booleano, data, valor,
binário, etc. Ex.: no cadastro de clientes, precisamos de informações básicas
7
como nome, RG, CPF, endereço e telefone. O atributo nome será alfanumérico
com 50 caracteres, o atributo RG será numérico com 10 posições , o CPF será
numéricos com 14 posições, o endereço será alfanuméricos com 50 caracteres e
o telefone será alfanuméricos com 14 posições.
Aqui ainda não sabemos qual será o SGBD adotado para a fase de
implementação. Isso permite manter um modelo de dados independente e que
possa satisfazer a diversas necessidades, evitando assim a manutenção de
diversos modelos, um para cada SGBD demarcado.
1.0.4-Modelo físico
No modelo físico, a preocupação já fica mais direcionada às características de
armazenamento físico do banco de dados.
Quando um atributo e tipificado como alfanumérico, é necessário verificar com o
SGBD trata esse tipo de dados (ex. varcher, char, string); o mesmo acontece se o
tipo for numérico (ex. number, real, integer).
Nessa hora devemos pensar se é mais vantajoso armazenar as tabelas separadas
dos índices em discos diferentes, ou se devemos separar uma tabela em mais
tabelas, segmentando e fragmentando, assim, o seu armazenamento.
É quando algumas regras de normalização são questionadas, pois o que pode ser
correto como normalização pode não ser tão prático ou útil no dia a dia. Será que
vale apena trabalhar com o modelo desnormalizado, se podemos quebrar algumas
dessas regras de modo consciente?
1.0.5- SQL
O SQL, que é a sigla para Structured Query Language, é uma linguagem padrão
para acesso a banco de dados, foi desenvolvido pela IBM em meados dos anos
70 como uma linguagem de manipulação de dados (DML - Data Manipulation
Language) para suas primeiras tentativas de desenvolvimento de bancos de
dados relacionais. A grande vantagem do SQL sobre modelos de dados anteriores
é que as operações realizadas sobre os dados são especificadas numa linguagem
não procedural e conjuntos de dados são manipulados com um único comando.
Isto faz com que os programadores não tenham de navegar por uma estrutura
8
complexa de banco de dados, reduzindo a quantidade de código necessário para
acessar os dados.
O SQL tornou-se de fato o padrão depois de 1986, quando o American National
Standards Institute (ANSI), a organização responsável pelos padrões industriais
nos Estados Unidos, endossou o SQL como linguagem padrão para os bancos de
dados relacionais. Desde então, o SQL já sofreu duas atualizações oficiais, uma
em 1989, e outra em 1992. A revisão de 1992, SQL-92 (ANSI X3.135-1992) é o
padrão usado atualmente, mas desde 1993 há um trabalho sendo desenvolvido
para atualizar o padrão de modo que este atenda às características das últimas
versões de bancos de dados relacionais lançadas no mercado. O novo padrão
SQL chama-se SQL3; o número 3 vem de 1993, o ano em que os trabalhos
começaram.
Em 1986, o ANSI publicou o primeiro padrão SQL, X3.135-1986. A International
Organization for Standardization (OSI) pubicou um padrão tecnicamente idêntico,
ISO 9075-1987, alguns meses depois em 1987. O padrão representava um
denominador comum das implementações SQL existentes e consequentemente
deixou de padronizar muitas características populares e necessárias da
linguagem. Este padrão continha características de SQL de quatro linguagens de
programação: COBOL, FORTRAN, Pascal e PL/I.
Em 1989, tanto ANSI quanto ISO publicaram padrões substitutos (ANSI X3.135-
1989 e ISO/IEC 9075:1989) que aumentaram a linguagem e acrescentaram uma
capacidade opcional de integridade referencial, permitindo que projetistas de
bancos de dados pudessem criar relacionamentos entre dados em diferentes
partes do banco de dados. No mesmo ano, o ANSI adicionou ao padrão suporte
para duas outras linguagens de programação, Ada e C.
Em 1992, ISO e ANSI publicaram a terceira revisão do padrão SQL, o SQL92
(X3.135-1992 e ISO/IEC 9075:1992).
Na mais nova versão, SQL3, a nova característica mais importante é a adição de
características de orientação a objetos na linguagem.
9
1.1.0 -Linguagem de definição de dados -DDL
Linguagem de definição de dados ( DDL, do Inglês Data Definition Language) é
uma linguagem de computador usada para a definição de estruturas de dados. O
termo foi inicialmente introduzido em relação ao modelo de banco de dados
Codasyl, onde o esquema de banco de dados era escrito em uma Linguagem de
Definição de Dados descrevendo os registros, campos e "conjuntos" que
consituíam o Modelo de dados do usuário. Inicialmente referia-se a um
subconjunto da SQL, mas hoje é usada em um sentido genérico para referir-se a
qualquer linguagem formal para descrição de estruturas de dados ou informação,
assim como esquemas XML.
Uma vez compilados, os parâmetros DDL são armazenados num conjunto de
arquivos denominado dicionário de dados (ou catálogo). O dicionário de dados
contém os metadados (dados a respeito das estruturas de armazenamento). O
SGBD sempre consulta os metadados a cada operação sobre o banco de dados.
Por exemplo, um determinado programa precisa recuperar alguns campos (nome,
CPF) de um arquivo de clientes. O SGBD irá verificar se os campos "nome" e
"CPF" estão definidos para este arquivo. O interpretador DDL processa os
comandos alimentados pelos DBAs na definição dos esquemas.
1.1.1 -Declarações Create
Create - utilizada para construir um novo banco de dados, tabela, índice ou
consulta armazenada. Uma declaração CREATE, em SQL, cria um objeto dentro
do Sistema de Gerenciamento de Banco de Dados Relacional (SGBDR). Os tipos
de objetos que podem ser criados dependem de qual SGBDR está sendo
utilizado, porém a maioria suporta a criação de tabelas, índices, usuários e banco
de dados. Alguns sistemas (tais como PostgreSQL) suportam o comando
CREATE, e outros comandos DDL, dentro de uma transação e portanto suportam
rollback.
Create database- cria um novo banco de dados
10
Create table- cria uma nova tabela
Create índex- cria um novo índice
Create view- cria uma nova visão
Create procedual- cria um novo procedimento
Create peckage – cria um novo pacote
Create funtion – cria uma nova função
1.1.2- Declarações Drop
Drop - remove um banco de dados, tabela, índice ou visão existente.
Uma declaração DROP em SQL remove um objeto de um sistema de
gerenciamento de banco de dados relacional(SGBDR). Os tipos de objetos que
podem ser removidos dependem de qual SGBDR esté sendo usado, mas a
maioria suporta a exclusão de tabelas, usuários e banco de dados. Alguns
sistemas (tais como o PostgreSQL) permitem que DROP e outros comandos
ocorram dentro de uma transação e portanto suportem roll back.
Drop database- remove um banco de dados
Esse comando não existe, pois, para executar os comandos SQL, é necessário
esta conectado a um banco de dados e não é possível “dropar” o banco em que
se está conectado.
Para se remover o banco de dados, basta remover do servidor de banco de dados
todos os arquivos e diretórios referentes ao banco que se quer remover.
Drop table- remove uma tabela
Drop índex- remove um índice
Drop view – remove uma visão
Drop procedure- remove um procedimento
Drop package- remove um pacote
Drop function – remove uma função.
11
1.1.3 -Linguagem de manipulação de dados - DML
Linguagem de manipulação de dados (ou DML, de Data Manipulation Language) é
uma família de linguagens de computador utilizadas para a recuperação, inclusão,
remoção e modificação de informações em bancos de dados. Pode ser
procedural, que especifica como os dados devem ser obtidos do banco; pode
também ser declarativa (não procedural), em que os usuários não necessitam
especificar o caminho de acesso, isto é, como os dados serão obtidos. O padrão
SQL é não procedural. DMLs foram utilizadas inicialmente apenas por programas
de computador, porém (com o surgimento da SQL) também têm sido utilizadas por
pessoas.
Principais comandos
As DMLs têm sua capacidade funcional organizada pela palavra inicial em uma
declaração, a qual é quase sempre um verbo. No caso da SQL, estes verbos são:
* Select
* Insert
* Update
* Delete
1.1.4-Linguagem de controle de dados – DCL
Linguagem de Controle de Dados, ou do inglês Data Control Language(DCL), é
uma linguagem de computador e um subconjunto de SQL, usada para controlar o
acesso aos dados em um banco de dados.
Exemplos de comandos DCL incluem:
* GRANT para permitir que usuários especificados realizem tarefas
especificadas.
* REVOKE para cancelar permissões previamente concedidas ou negadas.
12
Os seguintes privilégios podem ser CONCEDIDOS À ou REVOCADOS DE um
usuário ou papel:
* CONNECT
* SELECT
* INSERT
* UPDATE
* DELETE
* EXECUTE
* USAGE
Em Oracle, executar um comando DCL emite um commit implícito. Em
PostgreSQL, executar um comando DCL é transacional e pode suportar roll back.
1.1.5-Processamento de transações de banco de Dados
Uma transação é quando um banco de dados sai do seu modo íntegro e
consistente, realiza alguma operação de alteração de dados e retorna ao seu
modo íntegro e consistente.
Um banco de dados é composto de tabelas que estão inter-relacionadas umas
com as outras, de modo a representar o Diagrama Entidade Relacionamento DER
que foi modelado segundo o conceito do Modelo Entidade Relacionamento MER.
As ações a serem efetuadas no banco de dados, consistem basicamente em
gravar novos dados, consultar dados gravados existentes, modificar dados
previamente gravados existentes e remover dados previamente gravados
existentes.
Então podemos definir que existem 4 tipos de operações:
- gravar dados, que vamos tratar de agora em diante como ‘inserir dados’.
- consultar dados, que vamos continuar como está.
- modificar dados, que vamos tratar de agora em diante como ‘atualizar dados’.
- remover dados, que vamos tratar de agora em diante como ‘deletar dados’.
Destas operações, podemos afirmar que:
13
- a operação consultar dados não provoca modificações nos dados armazenados
no banco de dados.
- as operações inserir dados, atualizar dados, deletar dados provocam alterações
nos dados armazenados.
Um banco de dados deve sempre manter a sua integridade e consistência nos
dados armazenados, para garantir que as regras de negócio estabelecidas
estejam sendo cumpridas.
Neste momento dizemos que o banco de dados não está em transação. Porém
sempre que uma das três operações que provocam alterações nos dados
armazenados (inserir dados, atualizar dados e deletar dados) são executados,
dizemos que o banco de dados realizou uma transação.
CRUD é o acrônimo da expressão em língua Inglesa Create, Retrieve, Update e
Delete, usada para definir quatro operações básicas usadas em bancos de dados
relacionais (RDBMS) ou em interface para usuários para criação, consulta,
atualização e destruição de dados.
Para iniciar uma transação, o banco de dados recebe um aviso de início de
transação que e chamado de ‘início de transação’ ou ‘begin transaction’.
Ao final da transação, o banco de dados recebe outro aviso, agora indicando o
encerramento da transação que chamaremos de ‘fim de transação’ ou ‘end
transaction’.
Durante a realização de uma transação podemos colocar apenas um comando de
atualização de banco de dados ou vários comandos de atualização de banco de
dados.
Isto significa que uma transação pode ter uma única operação ou diversas
operações.
Dentro de uma transação podemos ter também diversos comandos de consulta de
dados, pois como estes comandos não modificam os dados armazenados, eles
não interferem na integridade ou consistência do banco de dados.
Quanto mais operações colocarmos dentro de uma única transação, mais
demorado e critico torna-se esta transação, porém o tamanho de uma transação
dependerá muito da ‘regra de negócio a ser cumprida’.
14
1.2.0-Propriedades ACID
Todo Sistema Gerenciador de Bando de Dados (SGBD) aplica em seu
funcionamento o conceito denominado ACID, que representa a inicial de quatro
propriedades fundamentais.
Atomicidade, Consistência,Integridade, Durabilidade. Um SGBD não pode
aplicar apenas algumas destas propriedades, todas as propriedades devem ser
cumpridas, senão não podemos considerar um SGBD de verdade.
Atomicidade
Dizemos que uma transação é atômica, pois a transação não é divisível em
partes, ou seja, a transação deve ser realizada por inteiro ou ela não pode ser
realizada.
Lembramos que uma transação pode ter várias operações de alteração de dados,
então ou cumprimos todas elas ou não realizamos nenhuma delas.
Ex. em uma transação realizamos a inclusão de um cliente novo, a geração de
uma nota fiscal e a baixa no estoque do produto vendido, ao final desta transação,
devemos confirmar a transação por inteiro e gravar todas estas operações, se esta
transação não se confirmar ao final, nenhuma destas operações pode ser gravada
no banco de dados, garantindo assim a atomicidade da transação.
Consistência
Uma transação quando inicia, os dados armazenados estão todos consistentes,
ao concluir a transação os dados devem estar consistentes novamente, ou seja,
as regras de negócio devem continuar sendo executadas e cumpridas.
Ex. se realizar uma transação em uma conta bancária, onde o cliente possui um
saldo de R$ 50,00 e não tem limite de crédito (não pode ficar negativo) e esta
15
transação for uma retirada de R$ 60,00 , esta transação não pode ser concluída
pois a consistência do banco de dados não estaria garantida deixando a conta
com um saldo negativo.
Integridade
É também conhecida como Isolamento de transações.
Uma transação deve ser íntegra/isolada, ou seja, as regras de negócio devem ser
cumpridas durante a realização das operações na transação independentemente
de existirem mais transações simultaneamente e ao final delas, esta integridade
deve permanecer. Ex. se for estabelecida uma regra de negócio onde um cliente
de uma vídeo locadora pode cadastrar até dois dependentes, mas que todo
dependente deve obrigatoriamente estar vinculado a um cliente, se um
determinado cliente for deletado do banco de dados, os dependentes deste cliente
deverão ser deletados também, pois se eles permanecerem no banco de dados, a
integridade desta regra de negócio estará comprometida e toda esta operação
ocorrer simultaneamente a outras transações no banco de dados, inclusive
podendo ser nas mesmas tabelas ou não.
Durabilidade
Uma transação depois que for realizada e confirmada deve obrigatoriamente ser
durável, ou seja não pode desaparecer do banco de dados sem que uma outra
transação realize esta operação.
Ex. um determinado dado que foi gravado em uma transação hoje, daqui a cinco
anos, se nenhuma outra transação modificar este dado, quando este dado for
consultado deverá apresentar o mesmo resultado do que foi gravado hoje, quando
a transação original foi realizada.
Confirmação ou não de uma transação
16
Quando terminamos uma transação, com quantas operações forem necessárias,
necessitamos confirmar ou não a realização desta transação.
A confirmação desta transação é realizada com a execução de um comando de
confirmação ou ‘commit’.
Neste momento as quatro propriedades do banco de dados Atomicidade,
Consistência, Integridade e Durabilidade são executadas e confirmadas estas
propriedades, a transação é confirmada e encerrada.
Mas se por acaso a transação não trouxe o resultado esperado, apesar dos
comandos de alteração já terem sido executados, ainda podemos nos arrepender
e cancelar a transação através do comando de cancelamento ou ‘rollback’.
Este comando desfaz as operações que estavam sendo realizadas até o início da
transação, levando a um ponto onde as quatro propriedades ainda permanecem
garantindo os dados do banco de dados.
Os comandos ‘commit’ e ‘rollback’ são muito conhecidos no ambiente dos
programadores de computador, analistas de sistemas e administradores de banco
de dados.
O comando ‘end transaction’ geralmente está implícito dentro dos comandos
‘commit’ e ‘rollback’.
Lembramos que um SGBD deve suportar diversas transações sendo realizadas
simultaneamente, por isso mesmo, as transações podem concorrer umas com as
outras, este assunto será tratado em ‘controle de concorrência’.
Independência de transação
Esta é outra propriedade de banco de dados que surgiu no final da década de 70 e
início da década de 80.
Inicialmente os SGBDs eram praticamente todos com transações dependentes,
isto significava que apesar do banco de dados ser multiusuário, suportando
diversas transações ao mesmo tempo, caso uma das transações tivesse algum
problema e a mesma fosse interrompida ou ‘abortada’, todas as demais
17
transações eram interrompidas também, derrubando o banco de dados como um
todo e provocando um rollback geral.
Esta situação deixava os fabricantes/fornecedores de SGBDs com um ponto de
vulnerabilidade na confiança sobre seus produtos.
Para resolver esta situação, foi estabelecido o conceito de independência de
transação ou ‘independent trans’.
Este conceito pregava a seguinte característica:
Se uma transação falhar e for necessário interrompê-la através do ‘abort’, que
interrompa apenas esta transação e no máximo alguma outra transação que
esteja na dependência dos dados desta transação interrompida.
Aquelas outras transações que estavam sendo realizadas em outros dados, deve
continuar sendo executada sem nenhuma interferência.
A esta característica damos o nome de ‘independent trans’.
1.2.1-Modelo de armazenamento de um banco de dados
Um banco de dados tem como finalidade armazenar dados de uma forma
organizada, coerente, consistente, integra e durável.
Quando um comando que modifica o estado do banco de dados, por exemplo
insert, update e delete, é executado, uma série de ações são desencadeadas.
O Sistema Gerenciador de Banco de Dados (SGBD), dispara internamente um
comando do tipo write para o sistema operacional do computador/servidor do
banco de dados.
Porém este comando não é imediatamente repassado para o sistema operacional,
porque se isto ocorresse haveria um estrangulamento na comunicação do SGBD
com o sistema operacional.
O que acontece então?
O comando write grava uma cópia dos dados afetados em um buffer do banco de
dados ainda na memória do servidor do banco de dados.
Este buffer tem um determinado tamanho na memória principal, que é configurado
e parametrizado pelo Administrador de Banco de Dados DBA.
18
Quando esta área de armazenamento de buffer fica cheia, o SGBD encaminha
uma ordem para o sistema operacional gravar todos estes buffers em uma área do
disco pertencente ao banco de dados que vamos chamar de LOG.
Depois que este LOG é gravado, uma confirmação é repassada ao SGBD
avisando que o LOG já foi devidamente gravado.
Com isto o SGBD já está pronto para descarregar todas as transações
confirmadas com write e que o sistema operacional está aguardando.
Este mecanismo visa diminuir a quantidade de IOs (input output) entre o sistema
operacional e os discos, pois sabemos que um dos maiores gargalos em
processamento de dados é exatamente a transferência de dados entre a memória
principal e os discos rígidos.
Esta transferência não envolve apenas dispositivos eletrônicos, mas dispositivos
eletros-mecânico também.
O modelo das informações das transações gravadas no log é baseado na
identificação do início da transação, descrição da transação e finalização da
transação.
< T , Start >
< T , tabela, campo, valor velho, valor novo >
< T , Commit >
1.2.2-Componentes do processamento de transações
Cada transação que está ocorrendo no banco de dados possui a sua própria área
de trabalho, com uma cópia individual dos dados acessados.
Buffer do banco de dados é o nome técnico que representa estes locais.
Buffer do banco de dados são as páginas do banco de dados na memória, é
controlado pelo banco de dados e/ou sistema operacional.
Quanto mais buffers de banco de dados tiverem, mais dados podem ser
carregados na memória principal do servidor do banco de dados, mais transações
podem ser realizadas simultaneamente e mais rápido pode ser o banco de dados.
19
Por isso dizemos que um servidor de banco de dados tem que ser exclusivo no
equipamento, não é recomendado colocar outras aplicações no mesmo
equipamento.
E quanto mais memória RAM o servidor tiver, melhor ainda.
Bancos de dados são verdadeiros consumidores de recursos computacionais
como processadores, memória RAM e discos.
Buffer do sistema são os buffers responsáveis pelo armazenamento das páginas
dos códigos objetos dos programas e das áreas de trabalho locais das transações
ativas.
Quem controla esta área é o gerenciador de memória virtual do sistema
operacional.
Buffer de log são as cópias das páginas do registro de log, de transações que
foram confirmadas pelo banco de dados e aguardando serem descarregadas em
disco.
O armazenamento secundário (discos rígidos do servidor do banco de dados)
pode ser dividido em:
Código objeto do sistema – programas aplicativos e sistema operacional
Área de troca de memória virtual – área em disco usado para armazenar páginas
da memória principal que não estão em uso no momento.
Armazenamento estável on-line – mantém os registros do log necessários para
uma recuperação de falha do banco de dados.
Armazenamento histórico estável – mantém os registros do log na forma de
histórico das transações antigas.
Recuperação de falhas de transação
Uma transação de banco de dados pode apresentar falha, nestes casos temos
duas ações possíveis:
Reexecução em cascata – para recuperarmos uma transação T, pode ser
necessário refazer diversas outras transações já confirmadas. Esta situação
20
acontece se depois da transação T ocorrer, outras transações utilizarem dos
dados atualizados por T.
Desfazer em cascata – cascading rollback é a situação onde diversas transações
precisam ser desfeitas. T1, T2 e T3 processadas, mas T1 apresenta uma falha e
as transações T2 e T3 serão desfeitas também, para manter a consistência.
Esta situação pode ocorrer quando o banco de dados utiliza o protocolo de
bloqueio de duas fases ou baseado em marcador de tempo.
Uma vez que a transação T2 já está compromissada, T2 não poderá ser abortada,
e a falha de T1 poderá deixar o banco de dados inconsistente, formando assim
uma situação impossível de recuperar.
Para evitar este tipo de situação, os SGBDs implementam protocolos de controle
de transação.
Como é utilizado o LOG na recuperação do processamento de transações
É realizada uma varredura completa do log.
Para evitar a leitura total do arquivo de log, utilizamos os pontos de verificação
(checkpoint) para reduzir o número de registros do log que precisarão ser lidos
durante uma recuperação do banco de dados.
Assim as transações que serão os nossos alvos são aquelas que iniciaram depois
do último ponto de verificação e as que ainda permanecem ativas.
A leitura do log é feita do final para o começo até encontrar um checkpoint.
Cada transação identificada com um commit será incluída em uma lista refaz.
Cada transação identificada com um start, que não estiver na lista refaz vai para a
lista desfaz.
Quando o checkpoint é localizado, a leitura reversa é encerrada.
O log será lido novamente no sentido inverso e cada transação que estiver na lista
desfaz, o processo undo é executado.
Continua a leitura até localizar o último start da lista refaz.
Varre o log para frente e executa redo para cada entrada na lista refaz.
DeadLock
21
Existem situações onde um problema transacional de concorrência de acesso
pode nos levar a uma situação de deadlock.
Abraço mortal é uma situação onde duas transações T1 e T2, cada uma bloqueou
inicialmente A e B respectivamente, e para concluírem suas transações agora
necessitam de B e A respectivamente.
Porém nenhuma das duas transações abre mão dos seus dados previamente
bloqueados.
Esta exceção é tratada pelo SBGD da seguinte forma:
Como A e B já estão bloqueadas, por T1 e T2, T1 não conseguirá B e T2 não
conseguirá A.
E conseqüentemente ambas as transações ficarão paradas. Esta é a situação de
deadlock, quando isto ocorrer, uma das duas transações receberá o erro
DEADLOCK e a outra prosseguirá normalmente como se nada tivesse ocorrido.
T1 e T2 estão corretos a nível de programação, inclusive se executado
novamente, podem ou não apresentar deadlock novamente.
Podemos prever o deadlock com algumas ações na programação, ações estas
que devem ser amplamente discutidas com os demais analistas da sua equipe e
com o DBA principalmente.
O esquema mais simples aponta para bloqueio de todos os dados necessários
logo no início da transação.
O problema que pode ocorrer com o bloqueio inicial dos dados é que a baixa
utilização dos dados bloqueados logo no início deixe muitos outros programas
parados esperando pelos dados por um longo período de tempo, atrapalhando o
desempenho do banco de dados e até mesmo causando um travamento
generalizado no sistema.
Existe outra situação complicada também, sempre que o seu programa é
executado ele recebe um erro de deadlock, ou seja é o eterno escolhido, a esta
situação chamamos de Starvation ou Inanição.
Neste caso, a sua lógica de programação deve ser revista com urgência.
Como o SGBD prevê, identifica e trata o deadlock ?
Existem basicamente duas formas de detecção e tratamento de deadlock.
22
Wait-die ou espere-morra é uma técnica não apropriativa, quando T1 requer um
dado bloqueado por T2, permite-se que T1 espere somente se o marcado de
tempo da transação for menor que T2 (T1 é mais velha que T2), T2 receberá o
erro de deadlock e T1 consegue o dado. Caso contrário (T1 é mais novo que T2),
T1 receberá o erro de deadlock e T2 seguirá em frente normalmente.
Wound-wait ou tome fôlego e espere já é baseado em uma técnica apropriativa,
quando T1 requer um item bloqueado por T2, T1 poderá esperar pelo dado
somente se o marcador de tempo de T1 for maior que T2 (T1 é mais novo que
T2), T2 receberá o erro de deadlock e T1 consegue o dado. Caso contrário (T1 é
as velho que T2), T1 receberá o erro de deadlock e T2 seguirá em frente
normalmente.
A maioria dos SGBDs comerciais utilizam a técnica wait-die dentro do seu núcleo.
Existem grafos de espera que permitem detecção de um deadlock e sua
conferência através de um algoritmo.
Depois de detectado, o SGBD parte para a escolha da vítima (qual é o programa
que vai receber o erro), sinalização do erro de deadlock para a vítima, abortar a
sua transação e desfazer a sua transação aplicando um rollback nas transações já
efetuadas pelo programa.
.
1.2.3-Controle de Concorrência
Um SGBD trabalha individualmente com uma transação muito bem, mas o grande
desafio para a sua consagração no mercado é sem dúvida a sua capacidade de
tratar diversas transações simultaneamente.
Hoje em dia é muito comum e fácil o acesso a computadores com vários
processadores ou então com processadores com vários núcleos, a esta
característica chamamos de multiprocessador.
Existe também o multiprocessamento, que é a capacidade do sistema operacional
executar mais de um programa ao mesmo tempo.
23
Isto pode ocorrer com um computador com um único processador, neste caso o
processador acaba realizando o processamento em paralelo de diversos
programas ao simultaneamente.
Se colocarmos mais processadores, ele vai distribuir as tarefas passando rotinas
de processamento para cada processador, de modo independente.
E se apenas um programa estiver sendo executado, apenas um processador é
utilizado, os demais ficam ociosos.
Mas existem sistemas operacionais mais inteligentes, que aproveitam a
capacidade de multiprocessadores dos computadores e realizam uma melhor
distribuição de carga de processamento.
Se apenas um programa estiver executando no servidor, o sistema operacional
divide as tarefas deste programa entre os diversos processadores do servidor,
otimizando assim a carga sobre um único processador e distribuindo entre os
vários processadores, acelerando em muito a conclusão do processo.
Este tipo de sistema operacional é conhecido como multiprocessamento simétrico
ou SMP, onde é realizado o balanceamento de carga.
O SGBD trabalha em conjunto com o sistema operacional para retirar a melhor
performance possível na execução de transações concorrentes, garantindo
inclusive a efetiva consistência de todas as transações envolvidas.
Um bom SGBD deve suportar e transacionar desde poucas transações ao mesmo
tempo até dezenas e centenas de transações simultaneamente.
A sua capacidade de resolver os problemas que possam ocorrer durante as
transações e a integridade que o mesmo garante, fazem com que o SGBD seja
confiável.
1.2.4-Escalonamento (schedules)
Quando diversas transações são executadas concorrentemente, a consistência do
banco de dados pode ser destruída apesar de cada transação individual estar
correta.
24
Podemos afirmar que o escalonamento representa a ordem cronológica da
execução de cada instrução no banco de dados.
Uma transação de um programa deve sair de um estado consistente e levar o
banco de dados para outro estado consistente também.
Surge então o conceito de seriabilidade, ou seja, o escalonamento das execuções.
Escalonamento serial
Um escalonamento serial consiste de uma seqüência de instruções de várias
transações na qual as instruções pertencentes a uma única transação aparecem
juntas naquele escalonamento.
1.2.5-Escalonamento não serial
Um escalonamento não serial consiste de uma seqüência de instruções de várias
transações intercaladas entre si, o que pode provocar temporariamente um estado
inconsistente.
Podemos concluir que o escalonamento não serial pode comprometer a
consistência do banco de dados e causar transtornos enormes.
Por uma questão óbvia o escalonamento não serial não é permitido nos SGBDs
comerciais mais famosos.
25
Então chegamos a uma tabela de comparação do escalonamento de conflito
serializável.
Protocolo baseado em bloqueios
Um modo de assegurar a seriabilidade é requerer que o acesso aos itens de
dados seja feito de uma maneira mutuamente exclusiva, isto é, enquanto uma
transação faz o acesso a um item de dado, nenhuma outra transação pode
modificar aquele item.
O método mais fácil de garantir isto, é fazer com que uma transação ao acessar
um dado, mantenha um bloqueio neste dado até o término da sua transação.
Formas de bloqueio
Bloqueio partilhado – se uma transação T obteve um bloqueio (lock) no modo
partilhado (representado por P) no item de dado A, então T pode ler este item A
mas não pode gravar A.
Bloqueio exclusivo – se uma transação T obteve um bloqueio (lock) no modo
exclusivo (representado por X) no item de dado A, então T pode ler este item A e
somente T poderá gravar A.
Bloqueio de duas fases – nesta forma de bloqueio, o protocolo divide-se em:
26
Fase de crescimento – uma transação pode obter bloqueios, mas não pode liberar
nenhum dos bloqueios feitos.
Fase de encolhimento – uma transação libera um dos bloqueios, mas não pode
obter nenhum outro bloqueio até concluir a transação atual.
Inicialmente, uma transação está na fase de crescimento, obtendo quanto
bloqueios forem necessários para a sua transação. Uma vez que libere um
bloqueio, a transação entrará na fase de encolhimento e não pode mais bloquear
nenhum outro dado, até que a transação atual termine. Só então ela poderá
começar outra transação com novos bloqueios.
Bloqueio baseado em grafos – nesta técnica, o modelo mais simples requer que
tenhamos o conhecimento anterior da ordem na qual os itens do banco de dados
serão utilizados, a única instrução permitida é o lock-x (modo exclusivo).
Os bloqueios são realizados utilizando a árvore de acesso aos dados. Muitos
dados desnecessários são bloqueados e pode comprometer outras transações.
É um protocolo livre de deadlock porém bloqueia muitos dados desnecessários
para a transação.
Bloqueio baseado em marcador de tempo – o método mais comum para fazer isso
é utilizar o esquema de ordenação por marcadores de tempo, criando duas
variáveis w-timestamp(A) e r-timestamp (A).
Estas variáveis contêm o marcador de tempo lógico do sistema para identificar nas
transações quem chegou primeiro e quem chegou depois no dado.
Os marcadores de tempo são atualizados toda vez que uma instrução read ou
write for executada.
27
1.3.0-Conclusão
Abordando as fazes de um projeto de banco de dados descobri que para projetar
um banco de dado e necessário ter um pleno conhecimento nas mais diversas
áreas e caminho da informática alem de exercitar bastante a pratica.
28
1.3.1 Bibliografia.
http://pt.wikipedia.org/wiki/Modelo_relacional
http://www.cos.ufrj.br/~marta/BdRel.pdf
http://www.profwillian.com/bdados/aula03/AulaSQL.htm
Livro didatico- Banco de Dados II –UNOPAR –Roberto Yukio Nishimura
UNOPAR- Web Aula 248606 - Wa - Ads - Sem 3 - Unidade 1 - Banco de Dados
II
29