Cliente/Servidor Bancos de Dados Cliente/Servidor Graça Bressan

Transcrição

1 Cliente/Servidor Bancos de Dados Cliente/Servidor Graça Bressan Graça Bressan/LARC

2 Cliente/Servidor Bancos de Dados Cliente/Servidor DBMS Modelo Relacional O modelo de gerenciamento de bases de dados relacionais foi desenvolvido, no início da década de 70 por E.F. Codd no IBM San Jose Research Lab. A IBM desenvolveu nesta época o protótipo do sistema de bases de dados relacionais denominado sistema R. DBMS Relacional: 20 anos após o desenvolvimento de sua teoria básica, somente em 1992 superou as vendas em relação aos outros tipos de bases de dados. Um banco de dados relacional consiste de: Relações representadas na forma de tabelas. Tuplas correspondem à linhas de uma tabela Atributos correspondem a colunas da tabela. Graça Bressan/LARC

3 Plataformas de Software e Hardware Historicamente, os RDBMS, DBMS relacionais, aparecerem para computadores de grande porte e minicomputadores. Hoje, servidores PC e máquinas Risc são rápidos e suportam discos de maior capacidade, o suficiente para conter bases de dados de pequenas organizações. Podem ser exploradas arquiteturas SMP (com multiprocessadores simétricos). Em termos de capacidade de armazenamento são insuficientes para bases de dados de maior porte tais como de 10 terabytes. Para mainframes, a própria IBM e a Computer Associates são os principais fornecedores de RDBMS. No mercado UNIX, os principais servidores RDBMS são Oracle, Sybase, Informix e Ingres. Estes fabricantes, assim como outros, estão tornando estes servidores disponíveis em sistemas não-unix, tais como IBM OS/2, Microsoft Windows NT e Netware Novell. Linguagem de Consulta e SQL Linguagem de consulta é uma linguagem utilizada para requisitar informações do banco de dados. No caso de banco de dados relacionais as linguagens de consulta se baseiam em álgebra ou cálculo relacional. A linguagem SQL, Structured Query Language (também chamada Sequel), foi desenvolvida pela IBM, no Laboratório de Pesquisa da IBM em San Jose, para ser a linguagem de consulta do sistema relacional R. A Oracle Corporation foi a primeira empresa a disponibilizar comercialmente uma versão do SQL, com o seu banco de dados Oracle, em No início da década de 80 a IBM colocou no mercado seus produtos SQL/DS e DB2. Em 1986 foi padronizada pela ANSI e pela ISO. Foi adotada como padrão pela SQL Access Group (SAG) e X/Open. O SQL se tornou a linguagem predominante da bases de dados para mainframes, minicomputadores e servidores de redes locais. Características da linguagem SQL É uma linguagem interativa para consultas específicas feitas por usuários finais. É uma linguagem de programação de bancos de dados. Pode ser embutida em linguagens tais como C, C++, COBOL, ou acessada por interfaces tais como a API do X/Open. É uma linguagem de definição e administração de dados. É uma linguagem para acesso em rede. A IBM utiliza SQL para acessar dados relacionais e não relacionais (IMS, por exemplo). Possui recursos para proteção dos dados em ambientes multiusuários e em rede: validação de dados, integridade de referências, rollback (undo transaction), lock automático, detecção e resolução de deadlocks em ambientes multiusuários e em LANs. Graça Bressan/LARC

4 Componentes do SQL Data Definition Language (DDL). Interactive data Manipulation Language (DML). Embedded data manipulation language (linguagem de manipulação de dados embutida). View definition (definição de visões). Authorization (autorização) Integrity (integridade) Transaction Control (controle de transações) Padrões ANSI e ISO:SQL-89 Foi definido como a interseção entre as versões correntes do SQL na época da definição. No final de 1989 a ANSI acrescentou ao SQL-89 um adendo com a definição do Embedded SQL que se refere à linguagem utilizada por programadores para acessar a base de dados de dentro de uma aplicação. A Embedded SQL define a API para acesso a um RDBMS. Os fornecedores acrescentaram às suas implementações de SQL-89 muitos recursos da versão DB2. Padrões ANSI e ISO:SQL-92 Também chamada SQL2. A inclusão de uma quantidade muito grande de novos recursos dificultou aos fornecedores com produtos no mercado se tornarem conformes ao novo padrão. Padrões ANSI e ISO:SQL3 Triggers, queries recursivas, coleções. Objetos SQL incluindo tipos definidos pelo usuário (ADT - Abstract Data Type). SQL/CLI - Callabel Level Interface: extensão do CLI definido pela SAG (SQL Access Group) da X/OPEN. A Microsoft divulgou que o futuro ODBC será conforme ao ISO CLI. SQL/PSM: define o SQL Persistent Storage Modules que corresponde a extensões do conceito de Stored Procedures e de linguagens procedurais. Também define tratadores de exceções para undo, redo e commit. Binding: mecanismos para permitir a união com outras linguagens e embeded SQL. Transações: define como bases de dados SQL participam de transações globais. A definição do SQL3 é conforme ao padrão XA da definição transacional da X/Open. SQL temporal: permite ao SQL manipular series temporais de dados, tais como "Quais foram as vendas do produto P4 em 1995". Graça Bressan/LARC

5 Evolução dos padrões SQL Estrutura Básica de SQL A estrutura básica de uma expressão SQL consiste das cláusulas select, from e where. Ex.: select nome-cliente from empréstimo where nome-agência = "Paulista" O resultado de uma consulta SQL é uma relação. SQL - Exemplos No exemplo será considerado o seguinte esquema de uma base de dados de manufatura: PARTS (PartNum, PartName) PRODUCTS (ProdNum, ProdName) BILL-OF-MATERIAL (ProdNum, PartNum, Quantity) VENDOR (VendNum, VendName, VendAddress) SUPPLIER (PartNum, VendNum, Price, VendPN) Graça Bressan/LARC

6 SQL - Exemplo 1: Consulta Recuperação de dados de uma tabela: O seguinte comando encontra todas as vendas e preços cujo PartNum do fornecedor seja 40235: select VendNum, Price from SUPPLIER where PartNum = SQL - Exemplo 2: Consulta Recuperação de dados de mais de uma tabela Para cada parte cujo preço seja menor que $15, obter o nome e endereço de cada fornecedor: select PartNum, Price, VendName, VendAddress from SUPPLIER, VENDOR where SUPPLIER.VendNum = VENDOR.VendNum AND Price < 15 SQL - Exemplo 3: Atualização Para aumentar o preço de todos os produtos de Los Angeles em 20%: update SUPPLIER set Price = 1.2 * Price where VendAddress = Los Angeles SQL - Exemplo 4: Visualização e Segurança da Base de Dados A segurança consiste em controlar o acesso ao nível de relações individuais. Cada usuário tem uma visão diferente da base de dados, por exemplo, um comprador pode ter acesso de leitura e escrita à relação VENDOR e SUPPLIER mas apenas pode ler BILL-OF-MATERIAL. Acesso do Cliente ao Servidor DBMS A aplicação cliente auxilia o usuário na montagem das consultas, esconde os detalhes da linguagem SQL, exibe os dados retornados, cria relatórios e ajuda a integrar os dados a outras aplicações cliente Graça Bressan/LARC

7 Enquanto o usuário enxerga um sistema mais amigável em termos de operação, a aplicação cliente se encarrega de construir os comandos SQL e enviar ao servidor como feito de forma tradicional. Tanto servidor quanto cliente devem estar cientes do esquema da base de dados. Os dados ficam armazenados no servidor conforme definido pelo esquema. O cliente utiliza o esquema para montar as consultas SQL e realizar atualizações. O desenvolvimento de aplicações cliente exige o uso de APIs e ferramentas para acesso, consulta e interação com o usuário de uma base de dados. As APIs não devem limitar o acesso a DBMS específicos. Arquitetura Cliente/Servidor com DBMS As operações em bases de dados seguem o padrão de requisição-resposta, isto é, o cliente envia um comando SQL ao servidor e espera a resposta do servidor. O cliente processa o resultado e trata as exceções. Uma aplicação que realiza acesso a uma base de dados consiste em geral dos seguintes módulos: Interface com o Usuário: leitura dos dados e exibição dos resultados. Lógica de Apresentação: Calcula tabelas, gráficos e planilhas. Lógica Computacional: realiza cálculos com os dados obtidos na consulta. Lógica de Informação: gera as consultas à base de dados e obtem os resultados. Módulo de Lógica de Informações O módulo de Lógica de Informação é o que realiza as consultas ao banco de dados SQL. O cliente passa comandos SQL através de mensagem ao servidor DBMS. O resultado de cada comando SQL é retornado ao cliente. O código que processa comandos SQL e os dados, residem no servidor. O servidor faz todo o processamento da consulta para obter o resultado que é passado ao cliente. Graça Bressan/LARC

8 Acesso do Cliente ao Servidor DBMS O cliente pode acessar um servidor SQL das seguintes formas: O cliente envia requisições SQL ao servidor SQL através da rede. O cliente chama Stored Procedures definidas no servidor SQL. Requisições SQL Stored Procedures Chamadas de Stored Procedures Stored Procedure é um mecanismo semelhante a RPC para bases de dados. São codificadas como seqüências de comandos SQL, compiladas e armazenadas no servidor SQL. O conceito de Stored procedure foi concebido pela Sybase em 1986 para melhorar o desempenho do SQL em redes. Com Stored procedure a lógica de informação fica do lado do servidor. Garante maior autonomia da base de dados pois mudanças em tabelas exigem apenas alterações na Stored Procedure e não na aplicação cliente. Stored Procedures são registradas no catálogo como os demais objetos da base de dados. O cliente ao chamar uma Stored Procedure, passa os parâmetros da consulta. Graça Bressan/LARC

9 Os resultados da consulta são retornados como parâmetros. Requisições SQL x Stored Procedures Stored procedures são favoráveis à utilização em rede pois permitem reduzir o tráfego de dados. Uma operação que exija vários comandos SQL podem ser substituídas por uma única chamada. Exemplo: aumentar em 10 % o salário de todos funcionários com salário menor R$200,00. Diferentes implementações de Stored Procedures Sybase e SQL Server Oracle 7/8 IBM DB2 Gupta SqlBase Informix. Middleware para Integração Cliente/Servidor API para SQL Permite ao cliente enviar requisições a um servidor SQL. Cada fornecedor de servidor SQL deve fornecer uma API SQL para uma multiplicidade de sistemas (DOS, Windows, OS/2, Macintosh). Alternativas: Embeded SQL (ESQL), CLI. Driver SQL Camada de software que executa no cliente e aceita as chamadas SQL e formata como uma mensagem a ser enviada para o servidor. Em geral são específicos do fornecedor. Pilhas de protocolos Sockets, Named Pipes, TCP/IP, por exemplo. Gateways para outros servidores DBMS Um gateway converte e redireciona as chamadas SQL para outro servidor DBMS. Exemplos de gateways: Oracle, Gupta, XDB, Informix, Sybase fornecem gateways para DB2. Ferramentas de administração de bases de dados operando no modo cliente/servidor. Ferramentas gráficas para desenvolvimento de aplicações cliente/servidor (GUI/OOUI) e para consulta. API de acesso ao SQL para Aplicações Cliente Aplicações cliente realizam o seguinte processamento: Gerar consultas à base de dados em enviar essas consultas ao servidor. Obter os dados retornados pelo servidor e integra-los à aplicação cliente. Criar relatório específicos para a aplicação. Graça Bressan/LARC

10 Mainframes tem efetuado esses processamentos através de Embedded SQL que funcionam como extensão das linguagens de programação de mainframe. Integração em Aplicações Cliente/Servidor Requisitos de middleware para integração de aplicações cliente/servidor com bases de dados: Independência de fornecedor: devem ser ocultadas ao cliente, as diferenças entre servidores de diferentes fornecedores. Independência de localização: o servidor de base de dados pode ser local ou remoto na rede. Pode estar até mesmo na própria máquina do cliente. Interface de programação aberta: aplicações PC, tais como planilhas, devem poder acessar o servidor DBMS sem programa de usuário. Usuários devem ser capazes de acessar, combinar e integrar dados de múltiplas bases de dados simultaneamente. SQL-92 Embeded SQL (ESQL) Embeded SQL é um recurso incorporado ao padrão ISO SQL-92 para permitir o uso de comandos SQL em linguagens de programação convencionais (C, COBOL, Pascal, Mumps, ADA, PL/I). Em geral, o programa deve ser processado por um pré-compilador de Embeded SQL que gera código fonte da linguagem utilizada. Uma dificuldade para o desenvolvedor é que a base de dados deve estar disponível durante o desenvolvimento do programa. CLI - Call Level Interfaces É uma alternativa ao Embeded SQL. Consiste de uma API de acesso aos comandos SQL e não requer pré-compilação ou disponibilidade da base de dados durante o desenvolvimento. As chamadas à API podem ser criadas em tempo de execução. CLIs disponíveis: X/Open SQL CLI Microsoft ODBC SAG CLI Em 1988, fornecedores de servidores de banco de dados se uniram no consórcio chamado SAG, SQL Access Group, com o objetivo de definir padrões de acesso a bases de dados SQL. O SAG colocou seus esforços em duas vertentes: 1. Definição de protocolos e mensagens padronizados para permitir a interoperabilidade entre clientes e servidores de bases de dados. 2. Definição da SQL Call Level Interface (CLI) como API de acesso a bases de dados de múltiplos fornecedores. Características do SAG CLI: Graça Bressan/LARC

11 Sintaxe e semântica para chamada de comandos SQL, Tipos de dados SQL, Provê tratamento padrão de erros, Define conjunto comum de catálogos do sistema incluindo tabela de estruturas, Possui recursos para conexão e desconexão. X/Open SAG CLI Em dezembro de 1994 foi concluída a primeira versão da definição do SAG CLI que passou ao controle da X/Open sendo denominada X/Open CLI. Chamadas disponíveis: Conexão ao driver local (3 chamadas), Preparação das requisições SQL (5 chamadas) Execução das requisições( 2 chamadas), Obtenção do resultado (7 chamadas), Conclusão do comando (3 chamadas), Encerrar a conexão (3 chamadas). ODBC CLI ODBC, Open Database Connectivity, foi definido pela Microsoft, sendo uma versão estendida do SAG CLI. A primeira versão do ODBC 1.0 liberada em A versão ODBC 2.0 inclui 61 chamadas distribuídas em três níveis: Núcleo: 23 chamadas básicas para conexão à base de dados, execução de comandos SQL, obter resultados, realizar commit e rollback de transações, tratar exceções, e terminar conexões. Nível 1: 19 chamadas para obter dados do catálogo, acessar BLOBS, e lidar com funções específicas do driver. Nível 2: 19 chamadas para acessar dados usando cursores e suporte a scroll. O X/Open CLI inclui as funções do Núcleo do ODBC e algumas funções de nível 1 e 2. Também inclui descritores SQL que não existem no ODBC. Fornecedores em geral estendem sua implementação do ODBC com funções não suportadas por outros fabricantes, tais como stored procedure. Embora a maioria dos fornecedores suportem ODBC, muitos também implementam uma API proprietária que em geral oferece melhor desempenho. Detalhes Administrados pelo Driver ODBC Diferenças entre cada implementação SQL. Formato que o servidor requer para suas requisições e o formato das respostas. As requisições e respostas são em geral encapsuladas em pacotes TCP ou UDP. Independência do protocolo de comunicação utilizado. Diferenças na forma como diferentes servidores codificam os dados. Por exemplo, o driver deve tratar alinhamento de dados, compressão, ordenação de bytes, etc. Gerenciamento de conexões entre cliente e servidor. Nomes e localizações das fontes dos dados. Graça Bressan/LARC

12 Clientes e Servidores em Ambiente ODBC ODBC - Open Database Connectivity O ODBC requer um driver cliente para cada tipo de servidor SQL. Este driver realiza a interface entre a API ODBC e o servidor de base de dados. Normalmente o fabricante do sistema DBMS fornece o driver. O driver deve levar em conta as características do servidor, sendo possível até mesmo ter drivers para servidores de bases de dados não-relacionais que fazem a conversão dos comandos da API em comandos de consulta da linguagem do servidor. Existem drivers ODBC para SQL Server, Sybase, Informix, Ingres, Oracle, entre outros, permitindo que a aplicação cliente que utilizar a interface ODBC, seja independente do fornecedor do servidor de base de dados. Pelo fato de ser uma camada padrão que se interpõe entre a aplicação e o servidor, pode ocorrer alguma perda de desempenho em relação às interfaces proprietárias. Assim, a escolha do ODBC deve levar em conta as vantagens da padronização contra as vantagens de soluções proprietárias. Clientes e Servidores em Ambiente ODBC Aplicação Excel para gerar uma lista de fornecedores com nome, endereço, PartNum e preços de itens fornecidos cujo preço seja menor que $15: Graça Bressan/LARC

13 1. No menu Data selecionar Get External Data. 2. Selecionar a fonte de dados denominada MANUFACTURING. 3. Adicione as tabelas (relações) necessárias, no caso, SUPPLIER e VENDOR. 4. Selecione os campos na ordem em que devem aparecer Nesta consulta os campos são PartNum, Price, VendName e VendAddress. A partir dessas operações o Excel constrói os comandos de consulta. 5. O Excel envia a seguinte cadeia de caracteres ao driver: SELECT PartNum, Price, VendName, VendAddress FROM SUPPLIER, VENDOR WHERE SUPPLIER.PartNum = VENDOR.VendNum AND Price < No menu File, selecionar Return Data to Microsoft Excel 7. Podem ser escolhidas as células destino, a inclusão de nomes de campos e a opção de salvar a consulta para uso futuro. Transações e Bases de Dados Uma transação é uma operação atômica usualmente sobre bases de dados. A operação deve ser completada corretamente ou não ser realizada. A operação não pode ser interrompida por outras operações sobre os mesmos dados. Se houver uma falha na execução da transação, deverá ser feito um roll back de forma que a transação fique em um estado como se nunca tivesse sido executada. O exemplo de uma aplicação bancária mostra como são críticas as operações sobre uma mesma conta corrente devendo ser controlada por transações. Se duas operações são realizadas na mesma conta corrente, para evitar inconsistências no valor do saldo, operações de saque e depósito devem ser feitas dentro de transações. O mecanismo de transação deverá garantir que, caso as operações sejam sobre uma mesma conta, uma transação deverá terminar para que a outra possa começar a ser executada. Este tipo de integridade de transação é uma característica de uma número cada vez maior de sistemas DBMS. O desempenho desses sistemas em geral é especificado em transações por segundo. Outra tendência é estender o ambiente cliente-servidor através da incorporação de um sistema de suporte transacional tal como o Tuxedo (dos laboratórios UNIX) e o Encina (da Transarc). A arquitetura X/Open especificou o DTP - Distributed Transaction Processing. O DTP define como aplicações, gerenciadores de transações, gerenciadores de recursos e gerenciadores de comunicação interagem. Graça Bressan/LARC

14 Arquiteturas de Servidores SQL Um processo por cliente Multithread Híbrida Servidor SQL: Arquitetura com um processo por cliente Existe um processo para cada cliente com seu próprio espaço de endereçamento. O banco de dados roda em processos de background. A escalação de processos é feita pelo sistema operacional. Vantagens: proteção de um usuário contra outro pois cada processo possui seu próprio espaço de endereçamento. Monitores transacionais podem garantir melhor desempenho Desvantagens: maior overhead para chaveamento de processos e maior gasto de memória. Exemplos: DB2/2 v1, Informix, Oracle v6. Servidor SQL: Arquitetura Multithread As conexões de usuários, aplicações e o gerenciador de bancos de dados rodam em um mesmo espaço de endereçamento através de múltiplos threads. O próprio sistema DBMS controla a escalação. Vantagens: menor overhead e menor gasto de memória. É mais portável pois usa poucos recursos do sistema operacional. Desvantagem: não existe proteção entre aplicações e sistema. Exemplos de servidores SQL: Sybase e SQL Server. Graça Bressan/LARC

15 Servidor SQL: Arquitetura Híbrida Consiste de três componentes: Programa multithread que recebe os pedidos de conexões de clientes e atribui o cliente a um processo despachante. Pool de processos despachantes que colocam mensagens de requisição em uma fila de mensagens e que retira a resposta da fila e encaminha ao cliente. Pool de processos servidores reutilizáveis que retiram tarefas da fila, executam e colocam a resposta na fila. Graça Bressan/LARC

16 Vantagens: proteção de um usuário contra outro sem overhead de criação de processos que ficam ativos permanentemente. Desvantagem: balanceamento de carga pior que o de TPs. Exemplos Oracle v7. Graça Bressan/LARC

17 DBMS Distribuído É um conjunto de bases de dados localizadas em diferentes sites conectados em rede tais que: Cada base de dados de um site é uma base de dados por si só; As diversas bases de dados atuam em cooperação de tal forma que um cliente tenha a ilusão de estar acessando uma única base de dados. DBMS Distribuído Em um DBMS Distribuído os dados são armazenados em servidores e as consultas a esses dados são processadas nesses servidores. O cliente envia a requisição de consulta ao servidor, recebe as respostas, realiza algum processamento do resultado e apresenta as respostas. A principal motivação para o uso de DBMS Distribuídos é o fato de que as grandes corporações, usuárias de DBMSs, também possuem organização distribuída tanto do ponto de vista lógico (divisões, departamentos, grupos) quanto físico (módulos industriais, laboratórios, agências, filiais, unidades de um campus). DBMS Distribuídos permitem que: A estrutura da base de dados espelhe a estrutura da organização; Os dados locais fiquem próximos dos lugares onde são utilizados com maior freqüência. Graça Bressan/LARC

18 DBMS Distribuído e Cliente-Servidor O princípio fundamental de uma base de dados distribuída é que ao usuário, deve se apresentar exatamente como uma base de dados não distribuída. DBMS Distribuídos têm fundamental importância em arquiteturas cliente-servidor pelas seguintes razões: Os grandes bases de dados precisam ser acessados por múltiplos usuários; Informações retornadas pelas consultas a bases de dados freqüentemente precisam ser integradas a outras aplicações. DBMS Distribuído e Cliente-Servidor Usuários podem compartilhar um DBMS centralizado em sistemas multiusuários, através de terminais. Esta forma de acesso deixa de explorar a grande quantidade de ferramentas de produtividade e aplicações existentes em estações de trabalho e computadores pessoais. PCs e Macs constituem plataformas versáteis e de baixo custo e que permitem: A uma aplicação cliente consultar uma base de dados para obter informações a serem exibidas a usuários. Obter dados de um DBMS e inserir esses dados em planilhas. Retirar dados de planilhas, inserindo-os em uma base de dados. Fazer consistências de dados antes de inseri-los em bases de dados. DBMS Distribuídos exigem os mesmos requisitos das demais aplicações cliente-servidor: desempenho, escalabilidade, confiabilidade, segurança, nomes e localização, replicação, controle de tempo e transparência. Em um sistema cliente-servidor o acesso à base de dados pode ser feito através do mecanismo de RPC ou através um protocolo de requisição-resposta utilizando a infraestrutura de troca de mensagens da camada de transporte da rede. Um servidor DBMS distribuído se situa sobre as demais camadas de software de uma máquina servidora. Graça Bressan/LARC

19 Princípio Fundamental e Regras de DBMS Distribuídos Ao usuário, um DBMS distribuído deve ter a mesma aparência de um sistema não distribuído. Este princípio dá origem a um conjunto de regras e objetivos que são: 1. Autonomia local 2. Não ser dependente de um site central 3. Operação contínua 4. Independência de localização 5. Independência de fragmentação 6. Independência de replicação 7. Processamento distribuído de consultas 8. Gerenciamento distribuído de transações 9. Independência de hardware 10. Independência de sistema operacional 11. Independência de rede 12. Independência de DBMS Estes objetivos ou regras são, em muitos casos interrelacionados. É importante distinguir o verdadeiro DBMS distribuído dos sistemas que provêm meramente acesso remoto a dados. Regras de DBMS Distribuídos 1. Autonomia Local Cada um dos sites em um sistema distribuído deve ser autônomo, isto é, todas as operações de um site são controladas por aquele site. Os dados locais pertencem ao site e são gerenciados localmente, não exigindo a interferência de outros sites. 2. Independência de um Site Central Todos os sites devem ser tratados como iguais, não dependendo de um site central para qualquer espécie de gerenciamento. Não pode existir, por exemplo, processamento centralizado de consultas, gerenciamento centralizado de transações ou serviço de nomes centralizados. 3. Operação Contínua Graça Bressan/LARC

20 A grande vantagem de sistemas distribuídos é que provêm maior confiabilidade e disponibilidade. Confiabilidade, definida como a probabilidade do sistema estar funcionando em um determinado momento, é aumentada pois continua em operação mesmo em caso de falha em um de seus componentes individuais. Disponibilidade, definida como a probabilidade de que o sistema se mantenha em funcionamento initerrupto por um determinado período, é aumentada pela mesma razão acima e também pela possibilidade de utilização de replicação. 4. Independência de Localização O usuário não precisa saber onde os dados estão fisicamente localizados. Na verdade, o usuário deve ter a ilusão de que todos os dados estão localizados em um único site. Esta característica facilita o desenvolvimento de programas e a migração dos dados de um site para outro. 5. Independência de Fragmentação O sistema suporta fragmentação de dados se uma dada relação pode ser dividida em partes para objetivos físicos de armazenamento. Fragmentação é desejável por razões de desempenho: os dados devem ser armazenados na localização onde são utilizados com maior frequência de forma que a a maioria das operações sejam puramente locais reduzindo o tráfico na rede. Por exemplo, seja a relação EMPLOYEE em um sistema que suporte replicação: FRAGMENT EMPLOYEE INTO N_EMP AT SITE New York WHERE DEPT# = D1 OR DEPT# = D3 L_EMP AT SITE Londres WHERE DEPT# = D2 ; Neste caso, D1 e D3 são departamentos de New York e D2 é um departamento de Londres e as tuplas dos funcionários de cada departamento estão localizados no próprio site do departamento. 6. Independência de Replicação Um sistema suporta replicação se uma dada relação, ou de forma geral, um fragmento, pode ser representado por cópias distintas, ou réplicas, armazenadas em diferentes lugares. Exemplo: REPLICATE N_EMP LN_EMP AT SITE Londres REPLICATE l_emp NL_EMP AT SITE New York As razões pelas quais a replicação é desejável são as seguintes: Graça Bressan/LARC

21 Maior desempenho pois as aplicações podem operar sobre cópias locais; Maior disponibilidade pois o objeto replicado ficará disponível para processamento enquanto existir uma cópia acessível. A principal dificuldade da replicação é a propagação das atualizações de dados. A independência de replicação significa que a replicação deve ser transparente ao usuário. O sistema deve realizar os acessos às replicas de forma a otimizar o atendimento às requisições dos usuários. 7. Processamento Distribuído de Consultas Seja uma consulta do tipo "Obtenha os funcionários de Londres que ganham mais que $ 3.500,00 por mês", feita por um site de New York. Se a base de dados for relacional e os dados estiverem localizados em Londres, a consulta exigirá o envio de uma mensagem contendo a requisição de New York para Londres e uma mensagem com a resposta de Londres para New York. A resposta consistirá das n tuplas que constituem o resultado da consulta. Se o sistema não for relacional exigirá 2*n trocas de mensagens entre New York e Londres pedindo os registros sucessivamente até completar a consulta. Se a consulta envolver várias cidades, deve haver preocupação quanto à otimização no processamento das consultas para reduzir a movimentação de dados pela rede. Por exemplom, a união de uma relação Rx armazenada no site X com uma relação Ry armazenada em um site Y pode ser feita movendo-se Rx para Y ou Ry para X ou Rx e Ry para um terceiro site Z. Dependendo do forma como a consulta é realizada, o tempo de resposta pode variar entre décimos de segundos até horas. 8. Gerenciamento Distribuído de Transações Em sistemas distribuídos, uma simples transação pode exigir a execução de código em diversos sites diferentes. Cada transação é constituída de agentes, cada um dos quais realiza o processamento em um determinado site. O sistema deve ter condições de perceber que dois diferentes agentes fazem parte de uma mesma transação e, neste caso, deve impedir uma situação de bloqueio mútuo (deadlock) entre eles. Além disso, o sistema deve garantir que a transação seja completada como um todo ou que, em caso de falha de um dos agentes, retorne o estado anterior à execução, como se a transação nunca tivesse sido iniciada. Um dos protocolos utilizados neste caso é o two-phase commit. 9. Independência de Hardware É desejável que os componentes do DBMS distribuído possa ser executado em diferentes plataformas permitindo a escolha do porte de máquina adequado a cada site e a escalabidade do sistema. Alguns sites exigem máquinas de grande porte para o armazenamento de seu DBMS local ao contrário de outros. Graça Bressan/LARC

22 É importante neste caso, que os dados possam ser integrados em todos essas plataformas e que o usuário tenha uma visão unificada do conjunto, como se todos compusessem uma única máquina. 10. Independência de Sistema Operacional Este é um objetivo que complementa o anterior. É desejável que o DBMS possa executar em diferentes plataformas e sistemas operacionais, incluindo diferentes sistemas operacionais para a mesma máquina, o que facilita a escalabidade e migração. Contudo não deve se perder de vista que o usuário deve ter uma visão unificada do sistema não enxergando as diferenças entre seus componentes individuais. 11. Independência de Rede Este objetivo também complementa os anteriores. Neste caso devem ser privilegiados os protocolos e equipamentos com atendam aos padrões pois garantirão o maior grau de conectividade. 12. Independência de DBMS O DBMS distribuído consistirá de instâncias de DBMSs existentes em diferentes sites. A homogeneidade de sistemas pode ser relaxada em função do uso de interfaces padronizadas por todos eles. Um site contendo Oracle e outro contendo Ingres devem ser capazes de conversarem entre si através do uso da definição padrão da interface. Neste caso, suporte à heterogeneidade é uma característica desejável aos DBMS de forma que possa participar em sistemas distribuídos. Questões a serem consideradas em DBMS Distribuídos Em DBMS distribuídos, muitas vezes os sites fazem parte de WANs cuja velocidade de comunicação é ainda lenta se comparada a comunicação local. Por esta razão, o sistema distribuído deve ser implementado de forma a minimizar a utilização da rede, isto é, minimizar a quantidade de dados transferidos. A distribuição e as limitações da rede de comunicação dão origem às seguintes questões a serem equacionadas na implementação de sistemas distribuídos: Processamento de consultas Gerenciamento de catálogos Propagação de atualizações Recuperação de falhas Controle de concorrência. Processamento de Consultas Exige otimizações de forma a minimizar a movimentação dos dados, mesmo que seja a custa do aumento do processamento e entrada e saída, que são negligenciáveis em relação ao tempo de comunicação. Graça Bressan/LARC

23 Podem ser utilizadas estratégias de paralelismo entre sites diferentes de forma a reduzir o tempo total de resposta. Gerenciamento de Catálogos Em um sistema distribuído, o sistema de catálogos inclui outras informações além de relações, views, índices e usuários. Também são necessárias informações de controle para permitir a independência de localização, fragmentação e replicação desejadas. Considerando algumas possibilidades: 1. Centralizada: o catálogo completo é armazenado em um único site central. Problema: viola a regra de não depender de um site central. 2. Completamente replicado: o catálogo completo é armazenado em cada site. Problema: cada atualização tem que ser propagada a todas réplicas do catálogo. 3. Particionado: cada site contém um catálogo dos objetos armazenados naquele site. O catálogo total é a união de todos os catálogos. Problema: torna as operações não locais muito dispendiosas. 4. Combinação de 1 e 3: cada site mantém seu próprio catálogo e um único site central contém a união de todos catálogos. Problema: é mais eficiente mas viola a regra de não depender de um site central. Propagação de Atualizações É o principal problema com replicação de dados. Um esquema comum de lidar com este problema é o que considera uma cópia como primária: Uma cópia de cada objeto replicado é designado cópia primária e as restantes são cópias secundárias. Cópias primárias de objetos diferentes podem residir em diferentes sites. A atualização é considerada concluída assim que a cópia primária for atualizada. Este site é responsável pela propagação das atualizações aos demais sites. Este esquema apresenta problemas adicionais decorrentes de ser vulnerável ao site da cópia primária. Existem soluções alternativas, tais como a que utiliza o mecanismo de two-phase commit, para realizar as atualizações em todas as réplicas. Recuperação de Falhas O mecanismo utilizado é o protocolo two-phase commit, necessário não só em ambientes distribuídos mas sempre que uma única transação puder interagir com outros gerentes de recurso autônomos. Graça Bressan/LARC

24 Controle de Concorrência O controle de concorrência é baseado em geral no mecanismo de lock sobre objetos. Em sistemas distribuídos, essas operações são propagadas através de troca de mensagens aos sites remotos resultando em aumento de overhead na troca de mensagens necessárias a confirmar e liberar o bloqueio. Um problema a ser evitado, é a ocorrência de deadlock envolvendo um ou mais sites como o do exemplo: 1. O agente da transação T2 no site X espera o agente da transação T1 no site X liberar o lock. 2. O agente da transação T1 no site X espera o agente da transação T1 no site Y completar. IBM Distribuded Relational Database Architecture - DRDA É a arquitetura de bases de dados distribuídas da IBM. Diversos fornecedores de DBMS possuem gateways para DRDA: Oracle, Sybase, Informix, XDB, Ingres, Progress, Gupta, Novell, entre outros. Características do IBM DRDA Protocolo de trocas de mensagens SQL Independência de infra-estrutura de transporte de rede (APPC/APPN ou TCP/IP). Preparação de programas multiplataforma. Suporte a SQL Estático e dinâmico. Diagnóstico de erros comum. Sintaxe SQL comum (recomendável SQL-92). Graça Bressan/LARC

25 Evolução de Bases de Dados Clientes de bases de dados estão se tornando mais poderosos e colocando maiores demandas sobre servidores e representação de dados. Um exemplo e a demanda em multimídia para representação de sons e imagens. Os RDBMS (Relational Data Base Management System) e os OO-DBMS (Object Oriented Data Base Management) orientados a objeto estão enfocando esta demanda e mudando a forma como clientes e servidores representam os dados. Os RDBMS comerciais estendem o modelo relacional puro para satisfazer a esses requisitos adicionais. Uma limitação são os campos de tamanho fixo para permitir a inclusão de textos e pior ainda no caso de hipertextos e gráficos. Esta necessidade é atendida pelos BLOBSs (Binary Large Objects). No caso de BLOBS não podem ser aplicadas operações tais como de busca de registros com um determinado conteúdo. OO-DBMS estende os benefícios de programação orientada a objeto para DBMS, podendo armazenar e recuperar objetos tipo BLOBS e outros objetos com estrutura complexa. A substituição de RDBMS por OO-DBMS não é imediata considerando que as companhias já realizaram muito investimento nos RDBMS. Uma solução de compromisso seria conciliar características de OO aos RDBMS. Bancos de Dados Orientados a Objeto ODBMS estende os benefícios de programação orientada a objeto para DBMS, podendo armazenar e recuperar objetos tipo BLOBS e outros objetos com estrutura complexa. Existe atualmente um consórcio denominado ODMG (Object Database Management Group) encarregado da definição de um padrão para ODBMS. Produtos de mercado: Jasmine, Poet, O2, Versant, Object Store. A idéia geral é que um ODBMS é um DBMS que armazena não dados mas objetos no sentido que encapsula um conjunto formado por estruturas de dados juntamente com os procedimentos (métodos) que operam sobre os dados. Implementam o conceito de Objetos Persistentes. Possuem um conjunto de facilidades entre as quais: linguagem para definição de classes de objetos ou tipo (DDL), linguagem de consulta OQL (Object Query Language) que trabalha sobre objetos, biblioteca de classes com classes de objetos pré-definidos. Bancos de Dados Objeto-Relacionais Estendidos Os RDBMS comerciais estendem o modelo relacional com conceitos de objeto para satisfazer a requisitos adicionais. O armazenamento de imagens, sons e vídeo é feito através do tipo BLOBS (Binary Large Objects). Produtos de mercado: Posgres Ilustra Graça Bressan/LARC

26 Servidores DBMS Universais Os servidores DBMS atuais tais como os DBMS Universais procuram apresentar características que favoreçam o uso de multimídia e integração com ambientes Web e facilidades de manipulação de objetos. Existem as versões Oracle/8 e DB2-IBM entre outros. São Bancos de Dados Relacionais (RDBMS) com recursos para operar com tipos complexos de dados tais como imagens, vídeo, áudio. Mantém características dos RDBMS incluindo SQL e recursos transacionais. Suportam tipos complexos de dados tais como texto, multimídia, áudio, vídeo e dados multidimensionais. Suportam operações complexas em sobre dados simples ou complexos. Características de Bancos de Dados Universais Mais adequados às ferramentas atuais para desenvolvimento de processos e GUIs. Mais adequados às arquiteturas Internet/Intranet. Suporte efetivo a ROLAP (Relational OnLine Analytic Processing) Bancos de Dados Universais: Produtos Informix Universal Server (pioneiro) Oracle 8 IBM DB2 Universal Database IBM DB2 Universal Data Base Características Extensível para objeto-relacional. Suporta Large objects (LOBs) de até 2 GB. Permite tipos de dados definidos pelo usuário SQL recursivo Possui extensões para suporte multimídia: imagem, vídeo e audio. Suporta aplicações Java e applets Java, API JDBC para requisições SQL dinâmicas. Conectividade com base de dados Web com conexões persistentes. Conectividade Cliente-servidor Replicação de dados, two-phase commit. Compatível com DRDA. Consultas paralelas, suporte a clusters e sistemas SMP e MPP. Graça Bressan/LARC

27 Plataformas Disponíveis que suportam o DB2 Universal Data Base AIX HP-UX SCO Solaris OS/2 Windows NT e Windows 95 Oracle 8 Banco de dados relacional com suporte para imagens, vídeo, áudio e dados espaciais. A partir da versão 7.3 incorporou o Oracle Video Server Option, Oracle ConText Option e o Oracle Spatial Data. Fim do Módulo Bancos de Dados Cliente/Servidor Graça Bressan/LARC