Com a independência gerada pelos sistemas de informação, os usuários necessitam acessar dados que estão armazenados nos bancos de dados das empresas.
Uma das possibilidades de armazenamento dos dados é através da centralização dos dados por parte das empresas, em um mainframe, que apresenta como principal vantagem a possibilidade de executá-los de forma local e permitir o controle dos dados de forma centrada. Infelizmente alguns problemas podem ser encontrados na utilização desse tipo de estrutura.
Se o único mainframe de armazenamento de dados sair do ar, todos os usuários ficarão impedidos de acessarem os dados até que o servidor esteja em funcionamento novamente.
Outro problema seria o custo de comunicação de vários terminais que estão amplamente distribuídos até o local central.
Para solucionar os problemas citados, um projeto alternativo aos bancos de dados centralizados seriam os bancos de dados distribuídos.
A idéia seria espalhar os dados entre as cidades de rede distribuídas, cada uma com o seu próprio dispositivo de armazenamento de dados, sendo todos esses dados distribuídos considerados um único banco de dados lógico. Quando um usuário ou processo em algum lugar da rede distribuída fizer uma consulta ao banco de dados, não é necessário saber onde estão os dados solicitados na rede, o usuário apenas efetua a consulta e o dado desejado é retornado. Esse tipo de característica é conhecida como transparência de localização, podendo se tornar algo complexo dependendo do tamanho da estrutura, sendo necessário um SGBD distribuído para o gerenciamento. Exemplo de distribuição de dados:
A empresa XPTO possui suas principais bases em São Paulo, Rio de Janeiro, Brasília (Matriz), Tókio e Bali. O banco de dados da empresa é uma base relacional muito importante que é utilizado em todas as suas filiais. O banco é formado por seis grandes tabelas (A,B,C,D,E e F).Considerando que o tempo de resposta de uma consulta feita, é muito importante.
Sugestão 1: Dispersar as seis tabelas entre a matriz e as filiais.
Se em alguns locais, algumas tabelas forem mais utilizadas que outras, colocar as tabelas nos locais que são utilizadas com maior freqüência.
Infelizmente, a distribuição de dados dessa maneira não amenizou o problema existente com os dados centralizados, e foi adicionado outro tipo de problema, que é a disponibilidade. Outro problema nesse tipo de estrutura estaria relacionado às junções, pois se uma consulta que é feita em qualquer filial necessitar de uma junção de duas ou mais tabelas, como as tabelas estão localizadas em locais diferentes, aumentaria significativamente a complexidade da estrutura.
Sugestão 2: Duplicar (replicar) as tabelas em dois ou mais locais.
Essa idéia possui tanto vantagens, como desvantagens. A vantagem está relacionada a disponibilidade, pois se as tabelas estiverem replicadas em dois ou mais locais, e um desses locais sair do ar, os usuários poderão acessar os dados que estejam replicados na outra filial. Como desvantagem, se uma tabela for replicada em vários locais, ocasionará um maior risco a segurança dos dados.
O maior problema que a replicação causa é o controle de concorrência dos dados.
Esse tipo de estrutura aumenta a disponibilidade dos dados, pois cada tabela está agora em dois locais. A vulnerabilidade dos dados e a concorrência são limitadas.
Problemas com esse tipo de estrutura?
Sim, a filial tenderia a se tornar um grande gargalo. O que poderia ser feito para melhorar esse projeto?
Para trazer melhorias e fazer o projeto realmente funcionar, é necessário que se tenha flexibilidade na colocação das tabelas replicadas, para elas proporcionarem um maior benefício. Para isso ser feito é necessário:
Colocar cópias das tabelas nos locais em que elas são utilizadas mais intensamente, minimizando os custos com as comunicações.
Assegurar que existam pelo menos duas cópias de tabelas importantes usadas freqüentemente, para se obter ganho de disponibilidade.
Limitar o número de cópias de tabelas para o controle de segurança e da concorrência.
Evitar que qualquer um dos locais torne-se um gargalo.
O gerenciamento do diretório distribuído
Quando falamos sobre banco de dados distribuídos, abordamos a transparência de localização. Pressupondo que quando uma consulta é feita em uma cidade da rede, o sistema sabe onde encontrar os dados que foram solicitados pela consulta. Mas de onde vem esse conhecimento? Um SGBD distribuído deve possuir um diretório que registre onde estão localizadas as tabelas do banco de dados, as cópias replicadas das tabelas e as partições das tabelas. Quando uma consulta é feita em alguma filial da empresa, o SGBD utiliza o diretório para descobrir onde os dados necessários estão localizados, mantendo a transparência de localização, fazendo com que os usuários ou processos que iniciaram a consulta, não saibam onde estão os dados.
Vantagens e desvantagens de um SGBD distribuído
Resumiremos as vantagens e desvantagens de um SGBD distribuído, incluindo as vantagens e desvantagens de um SGBD centralizado, para fins de comparação.
SGBD centalizado:
Vantagens:
Auto grau de segurança. Concorrência, controle de cópias de segurança e recuperação;
Não necessita de diretório distribuído;
Não existe a necessidade de junções distribuídas. Desvantagens:
Todo acesso aos dados que não seja localmente gera custos de comunicação;
O local em que o banco está armazenado pode se tornar um gargalo; Possui problemas de disponibilidade.
Dispersando as tabelas pela rede (sem replicação e particionamento):
Vantagens
Autonomia local;
Custo de comunicação reduzido; Aumento da disponibilidade. Desvantagens
Diversos locais tem que se preocupar com a segurança; Requer um diretório distribuído;
Requer junções distribuídas.
Tabela particionadas:
Vantagens
Maior autonomia local;
Custo de comunicação reduzido Desvantagem
Recuperar uma parte ou toda a tabela pode requerer vários acessos a vários locais.
Módulo 16 - Middleware
Neste capítulo, falaremos da camada Middleware, destacando o seu papel e a sua importância para os sistemas de informação distribuídos.
O termo middleware representa uma camada de software que possibilita a comunicação entre as aplicações distribuídas. A comunicação desempenhada pela middleware promove a diminuição da complexidade e heterogeneidade de todos os sistemas envolvidos e suas diversidades, resumindo, é a camada que promove serviços que realizam a comunicação entre categorias diversificadas de aplicações de forma transparente.
Quando trabalhamos com sistemas distribuídos, a adaptação entre os sistemas heterogêneos é uma necessidade, pois envolve tanto sistemas atuais, como sistemas antigos.
Os componentes que formam uma middleware promovem a divisão entre o ambiente de execução e o ambiente de programação.
Comunicação através de middleware
Observe na imagem que todo o processamento entre as aplicações é feito de forma transparente. Toda a heterogeneidade que existe entre as aplicações, é totalmente tratada pela middleware.
A proposta inicial
A middleware logo que foi criada tinha a função de unir os componentes de um sistema distribuído, orientando a forma de comunicação entre os componentes existentes. Atualmente, as funções da middleware tornaram-se bem mais importantes, passando a integrar aplicações completas tanto dentro da organização, como entre as organizações.
A importância da padronização
A padronização de uma middleware é um ponto importante a ser observado, pois o relacionamento e integração entre aplicações diferentes pode ser um problema, devido às diversidades existentes, e a ligação entre aplicações desenvolvidas por linguagens distintas ser suportada por poucos tipos de
middleware.
OBS: Um exemplo de middleware que suporta a integração entre aplicações desenvolvidas em linguagens diferentes é o CORBA (Commom Object Request
Broken Architecture). Essa middleware permite o mapeamento de uma IDL
Características importantes em uma middleware: Flexibilidade
Performance
Essas duas características são mutuamente exclusivas, pois uma alta flexibilidade impede a alta performance e vice-versa. O ideal é que seja feito um balanceamento entre as duas características.