A proposta do esquema global único para o projeto de um SBDH é derivada dire- tamente dos bancos de dados distribuídos. O esquema global é somente outra ca- mada sobre os esquemas externos locais que fornece uma independência de dados adicional. A principal diferença entre sistemas distribuídos e os sistemas com es- quema global é que, no segundo, os esquemas locais são desenvolvidos indepen- dentemente do esquema global. Outra grande diferença é que sistemas de esquema global podem integrar esquemas locais de múltiplos modelos de dados. Esta pro- posta faz com que o acesso aos dados globais sejam bastante amigáveis. Usuários globais vêem um único banco de dados integrado. A interface global é indepen- dente de toda a heterogeneidade dos SGBDs locais. Para usuários e aplicações po- dem ser definidas visões específicas no topo do esquema global. Este é normalmente replicado em cada nó componente para tornar o acesso eficiente. O esquema global único é construído através da integração dos esquemas dos ban- cos de dados locais. Esta integração normalmente requer uma homogeneidade dos conflitos existentes entre os esquemas componentes. Devido às diferenças de re- presentação e as interdependências entre dados em diferentes nós, este processo torna-se bastante complexo. Apesar de existir muitas técnicas/metodologias para o processo de integrar múltiplos e distintos esquemas, este ainda é um processo muito dependente do trabalho humano. Os projetistas do SGBDH devem possuir um grande conhecimento de todos os esquemas locais e dos requisitos globais para poder decidir como integrá-los. O maior problema desta proposta é justamente o conhecimento geral necessário para projetar tal esquema.
Outra dificuldade apresentada por esta proposta está na parte de manutenção do esquema global. Mudanças nos esquemas locais devem ser refletidas no esquema global. As técnicas de integração usadas no projeto do esquema global e os tipos de mudanças nas representações dos dados locais podem complicar o mapeamento destas a nível global. Mudanças locais podem forçar a reconsideração de muitas decisões de projeto feitas durante o processo inicial de integração. Novamente, a pessoa responsável pela administração do BD (DBA) deve possuir um grande co- nhecimento global de todos os esquemas locais, do esquema global e das decisões iniciais do projeto.
Para amenizar os problemas encontrados no projeto do esquema global único pode ser utilizado esquemas globais parciais. Estes são os chamados sistemas de bancos
de dados federados. Para os usuários globais deste sistema, um determinado es-
quema parcial aparece como um esquema global único porque eles não acessam partes do sistema que não estejam incluídas neste esquema parcial [Pire97]. A proposta de linguagem de multidatabase [MRJ99, LMR90] busca resolver al- guns dos problemas associados com os esquemas globais, tais como nível de co- nhecimento exigido dos administradores (DBAs), tempo de desenvolvimento necessário para a criação do esquema global (parciais ou único), as dificuldades de manutenção e os requisitos de processamento/armazenamento dos nós locais componentes. Um exemplo de sistema que utiliza essa solução é o MRDSM, com a linguagem MSQL [LMR90].
Ao contrário do esquema global, esta proposta coloca grande parte da responsabi- lidade de integração, sobre o usuário. Mas, de certa forma, fornece funções de su- porte e maior controle da informação. São fornecidos operadores adequados e construtores específicos para os usuários resolverem os conflitos semânticos a vár- ios níveis de abstração. A maioria da linguagens de múltiplos bancos de dados são similares ao SQL com um acréscimo significante na sua funcionalidade.
Os sistemas que utilizam-se destas linguagens, devem fornecer ao usuário quais são as informações disponíveis e os locais onde podem ser encontradas. É neces- sário que o usuário saiba exatamente qual informação é necessária e o local pro- vável de sua localização. Ou seja, a responsabilidade de integração antes dada ao administrador global (na alternativa do esquema global), agora é passada para os usuários ou administrador local, que são responsáveis por entender os esquemas e ainda de detectar e resolver os conflitos semânticos. Aqui, os usuários devem ter conhecimento global das diferenças de representação e a origem dos dados, sendo que apenas das informações a serem utilizadas. A linguagem deve oferecer opera- dores adequados para que os usuários resolvam os conflitos semânticos em vários níveis de abstração. Algumas dessas características interessantes da linguagem MSQL apresentadas em [BBE98] são: Nomes globais, Dependências entre bancos de dados e Consultas entre banco de dados.
Uma grande facilidade acrescida nestas linguagens envolve a manipulação de re- presentação de dados. Como existem diferenças de representação na execução de uma consulta, a linguagem deve ser capaz de transformar a informação fonte na representação mais significativa para o usuário.
[SL90] aponta a metodologia de acoplamento fraco como a melhor solução para sistemas com um grande número de bancos de dados autônomos utilizados apenas para leitura, como por exemplo, sistemas de informações públicas. Já a metodolo- gia de acoplamento forte é apontada como melhor solução para sistemas que ne- cessitam dos controles extras providos por esta metodologia. Deve-se levar em consideração os objetivos do SBDH no momento da escolha da arquitetura ade- quada. Se o objetivo é montar um sistema que seja utilizado por usuários leigos, com certeza os sistemas interoperáveis e os sistemas de linguagens de multidata-
bases não devem ser escolhidos.