Arquiteturas de Banco Dados Introdução Atualmente, devem-se considerar alguns aspectos relevantes para atingir a eficiência e a eficácia dos sistemas informatizados desenvolvidos, a fim de atender seus usuários nos mais variados domínios de aplicação: automação de escritórios, sistemas de apoio a decisões, controle de reserva de recursos, controle e planejamento de produção, alocação e estoque de recursos, entre outros. Tais aspectos são: 1. 2. 3. 4. 5. 6. 1. Os projetos Lógico e Funcional do Banco de Dados devem ser capazes de prever o volume de informações armazenadas a curto, médio e longo prazo. Os projetos devem ter uma grande capacidade de adaptação para os três casos mencionados; 2. Deve-se ter generalidade e alto grau de abstração de dados, possibilitando confiabilidade e eficiência no armazenamento dos dados e permitindo a utilização de diferentes tipos de gerenciadores de dados através de linguagens de consultas padronizadas; 3. Projeto de uma interface ágil e com uma "rampa ascendente" para propiciar aprendizado suave ao usuário, no intuito de minimizar o esforço cognitvo; 4. Implementação de um projeto de interface compatível com múltiplas plataformas (UNIX, Windows NT, Windows Workgroup, etc); 5. Independência de Implementação da Interface em relação aos SGBDs que darão condições às operações de armazenamento de informações (ORACLE, SYSBASE, INFORMIX, PADRÃO XBASE, etc). 6. Conversão e mapeamento da diferença semântica entre os paradigmas utilizados no desenvolvimento de interfaces (Imperativo (ou procedural), Orientado a Objeto, Orientado a evento), servidores de dados (Relacional) e programação dos aplicativos (Imperativo, Orientado a Objetos). Arquiteturas As primeiras arquiteturas usavam mainframes para executar o processamento principal e de todas as funções do sistema, incluindo os programas aplicativos, programas de interface com o usuário, bem como a funcionalidade dos SGBDs. Esta é a razão pela qual a maioria dos usuários fazia acesso aos sistemas via terminais que não possuíam poder de processamento, apenas a capacidade de visualização. Todos os processamentos eram feitos remotamente, apenas as informações a serem visualizadas e os controles eram enviados do mainframe para os terminais de visualização, conectados a ele por redes de comunicação. Como os preços do hardware foram decrescendo, muitos usuários trocaram seus terminais por computadores pessoais (PC) e estações de trabalho. No começo os SGBDs usavam esses computadores da mesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execução de programas aplicativos e processamento da interface do usuário eram executados em apenas uma máquina. Gradualmente, os SGBDs começaram a explorar a disponibilidade do poder de processamento no lado do usuário, o que levou à arquitetura cliente-servidor. A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computação onde um grande número de PCs, estações de trabalho, servidores de arquivos, impressoras, servidores de banco de dados e outros equipamentos são conectados juntos por uma rede. A idéia é definir servidores especializados, tais como servidor de arquivos, que mantém os arquivos de máquinas clientes, ou servidores de impressão que podem estar conectados a várias impressoras; assim, quando se desejar imprimir algo, todas as requisições de impressão são enviadas a este servidor. As máquinas clientes disponibilizam para o usuário as interfaces apropriadas para utilizar esses servidores, bem como poder de processamento para executar aplicações locais. Esta arquitetura se tornou muito popular por algumas razões. Primeiro, a facilidade de implementação dada à clara separação das funcionalidades e dos servidores. Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples são delegadas às máquinas clientes mais baratas. Terceiro, o usuário pode executar uma interface gráfica que lhe é familiar, ao invés de usar a interface do servidor. Desta maneira, a arquitetura cliente-servidor foi incorporada aos SGBDs comerciais. Diferentes técnicas foram propostas para se implementar essa arquitetura, sendo que a mais adotada pelos Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) comerciais é a inclusão da funcionalidade de um SGBD centralizado no lado do servidor. As consultas e a funcionalidade transacional permanecem no servidor, sendo que este é chamado de servidor de consulta ou servidor de transação. É assim que um servidor SQL é fornecido aos clientes. Cada cliente tem que formular suas consultas SQL, prover a interface do usuário e as funções de interface usando uma linguagem de programação. O cliente pode também se referir a um dicionário de dados o qual inclui informações sobre a distribuição dos dados em vários servidores SQL, bem como os módulos para a decomposição de uma consulta global em um número de consultas locais que podem ser executadas em vários sítios. Comumente o servidor SQL também é chamado de back-end machine e o cliente de front-end machine. Como SQL provê uma linguagem padrão para o SGBDRs, esta criou o ponto de divisão lógica entre o cliente e o servidor. Atualmente, existem várias tendências para arquitetura de Banco de Dados, nas mais diversas direções. Resumo das arquiteturas de SGBDs Plataformas centralizadas: Na arquitetura centralizada, existe um computador com grande capacidade de processamento, o qual é o hospedeiro do SGBD e emuladores para os vários aplicativos. Esta arquitetura tem como principal vantagem a de permitir que muitos usuários manipulem grande volume de dados. Sua principal desvantagem está no seu alto custo, pois exige ambiente especial para mainframes e soluções centralizadas. Sistemas de Computador Pessoal - PC: Os computadores pessoais trabalham em sistema stand-alone, ou seja, fazem seus processamentos sozinhos. No começo esse processamento era bastante limitado, porém, com a evolução do hardware, tem-se hoje PCs com grande capacidade de processamento. Eles utilizam o padrão Xbase e quando se trata de SGBDs, funcionam como hospedeiros e terminais. Desta maneira, possuem um único aplicativo a ser executado na máquina. A principal vantagem desta arquitetura é a simplicidade. Banco de Dados Cliente-Servidor: Na arquitetura Cliente-Servidor, o cliente (front_end) executa as tarefas do aplicativo, ou seja, fornece a interface do usuário (tela, e processamento de entrada e saída). O servidor (back_end) executa as consultas no DBMS e retorna os resultados ao cliente. Apesar de ser uma arquitetura bastante popular, são necessárias soluções sofisticadas de software que possibilitem: o tratamento de transações, as confirmações de transações (commits), desfazer transações (rollbacks), linguagens de consultas (stored procedures) e gatilhos (triggers). A principal vantagem desta arquitetura é a divisão do processamento entre dois sistemas, o que reduz o tráfego de dados na rede. Banco de Dados Distribuídos (N camadas): Nesta arquitetura, a informação está distribuída em diversos servidores. Como exemplo, observe a abaixo. Cada servidor atua como no sistema cliente-servidor, porém as consultas oriundas dos aplicativos são feitas para qualquer servidor indistintamente. Caso a informação solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se de obter a informação necessária, de maneira transparente para o aplicativo, que passa a atuar consultando a rede, independente de conhecer seus servidores. Exemplos típicos são as bases de dados corporativas, em que o volume de informação é muito grande e, por isso, deve ser distribuído em diversos servidores. Porém, não é dependente de aspectos lógicos de carga de acesso aos dados, ou base de dados fracamente acopladas, em que uma informação solicitada vai sendo coletada numa propagação da consulta numa cadeia de servidores. A característica básica é a existência de diversos programas aplicativos consultando a rede para acessar os dados necessários, porém, sem o conhecimento explícito de quais servidores dispõem desses dados. Arquitetura Distribuída N camadas Abstração de dados Um SGBD é composto de uma coleção de arquivos inter-relacionados e de um conjunto de programas que permitem aos usuários fazer o acesso a estes arquivos e modificar os mesmos. O grande objetivo de um sistema de banco de dados é prover os usuários com uma visão abstrata dos dados. Isto é, o sistema omite certos detalhes de como os dados são armazenados e mantidos. Entretanto, para que o sistema possa ser utilizado, os dados devem ser buscados de forma eficiente. Este conceito tem direcionado o projeto de estrutura de dados complexas para a representação de dados em um banco de dados. Uma vez que muitos dos usuários de banco de dados não são treinados para computação, a complexidade está escondida deles através de diversos níveis de abstração que simplificam a interação do usuário com o sistema. Nível físico: o nível mais baixo de abstração descreve como os dados estão realmente armazenados. No nível físico, complexas estruturas de dados de baixo nível são descritas em detalhes; Nível conceitual: o próximo nível de abstração descreve quais dados estão armazenados de fato no banco de dados e as relações que existem entre eles. Aqui o banco de dados inteiro é descrito em termos de um pequeno número de estruturas relativamente simples. Embora as implementações de estruturas simples no nível conceitual possa envolver complexas estruturas de nível físico, o usuário do nível conceitual não precisa preocupar-se com isso. O nível conceitual de abstração é usado por administradores de banco de dados, que podem decidir quais informações devem ser mantidas no BD; Nível de visões: o mais alto nível de abstração descreve apenas parte do banco de dados. Apesar do uso de estruturas mais simples do que no nível conceitual, alguma complexidade perdura devido ao grande tamanho do banco de dados. Muitos usuários do sistema de banco de dados não estarão interessados em todas as informações. Em vez disso precisam de apenas uma parte do banco de dados. O nível de abstração das visões de dados é definido para simplificar esta interação com o sistema, que pode fornecer muitas visões para o mesmo banco de dados. Segue ilustração da arquitetura e referente abstração de dados envolvida. Uma analogia com o conceito de tipos de dados em linguagens de programação pode esclarecer a distinção entre os níveis de abstração. A maioria das linguagens de programação de alto nível tem suporte para a noção de um tipo de registro. Por exemplo, numa linguagem como Pascal podemos declarar um registro assim: type cliente = record nome: string; rua: string; cidade: string; end; Isto define um novo registro chamado cliente com três campos. Cada campo tem um nome e um tipo associado a ele. Um banco privado pode ter diversos tipos de registros incluindo: contas, com campos número e saldo; funcionário, com campos nome e salário. No nível físico, um registro cliente, conta ou funcionário pode ser descrito como um bloco de posições de armazenamento consecutivas (por exemplo, palavras ou bytes). No nível conceitual, cada registro destes é descrito por uma definição de tipo, ilustrado anteriormente e o inter-relacionamento entre esses tipos de registros é definido. Finalmente, no nível de visões, diversas visões do banco de dados são definidas, por exemplo: os contadores de um banco vêem apenas a parte do banco de dados que possui informações sobre contas dos clientes. Eles não podem ter acesso a informações que se referem a salários dos funcionários. Independência de dados Vimos três níveis de abstração pelos quais o banco de dados pode ser visto. A habilidade de modificar a definição ded um esquema em um nível sem afetar a definição de esquema num nível mais alto é chamada de independência de dados. Existem dois níveis de independência dos dados: Independência física de dados: é a habilidade de modificar o esquema físico sem a necessidade de reescrever os programas aplicativos. As modificações no nível físico são ocasionalmente necessárias para melhorar o desempenho; Independência lógica de dados: é a habilidade ded modificar o esquema conceitual sem a necessidade de reescrever os programas aplicativos. As modificações no nível conceitual são necessárias quando a estrutura lógica do banco de dados é alterada (por exemplo, a adição de contas de bolsas de mercado num sistema bancário). A independência lógica dos dados é mais difícil de ser alcançada do que a independência física, porém os programas são bastante dependentes da estrutura lógica dos dados que eles acessam. O conceito de independência dos dados é similar em muitos aspectos ao conceito de tipos abstratos de dados em modernas linguagens de programação. Ambos escondem detalhes de implementação do usuário. Isto permite ao usuário concentrar-se na estrutura geral em vez de detalhes de baixo nível de implementação. AULA: MODELOS DE DADOS Fundamental à estrutura de um banco de dados é o conceito de modelo de dados, uma coleção de ferramentas conceituais para descrição de dados, relacionamentos de dados, semântica de dados e restrições de consistência. Os vários modelos de dados que têm sido propostos dividem-se em três diferentes grupos: modelos lógicos baseados em objetos, modelos lógicos baseados em registros e modelos físicos de dados. MODELOS LÓGICOS BASEADOS EM OBJETOS Modelos lógicos baseados em objetos são usados na descrição de dados nos níveis conceitual e de visões. Eles se caracterizam pelo fato de fornecerem, de modo conveniente, capacidades de estruturação flexíveis e admitirem restrições de dados para serem explicitamente especificados. Existem muitos modelos diferentes e é possível que outros apareçam. Alguns dos mais conhecidos são: Modelo entidade-relacionamento; Modelo orientado a objetos; Modelo binário; Modelo semântico de dados; Modelo infológico; Modelo funcional de dados. O modelo entidade-relacionamento tem ganhado ao longo do tempo grande aceitação no projeto de banco de dados, sendo bastante utilizado. O modelo orientado a objetos inclui muitos dos conceitos no modelo entidade-relacionamento, mas representa códigos executáveis assim como dados. Modelo Entidade-Relacionamento (MER) O modelo entidade-relacionamento é baseado em uma percepção de um mundo real que consiste em uma coleção de objetos básicos chamados entidades, e em relacionamentos entre estes objetos. Uma entidade é um objeto que é distinguível de outro objeto por um conjunto específico de atributos. Por exemplo, os atributos número e saldo descrevem uma conta particular em um banco. Um relacionamento é uma associação entre várias entidades. Por exemplo, um relacionamento ContaCliente associa um cliente a cada conta que ele possui. O conjunto de todas as entidades de um mesmo tipo e o conjunto de relacionamentos do mesmo tipo são denominados conjuntos de entidades e conjuntos de relacionamentos, respectivamente. Em acréscimo a entidades e relacionamentos, o modelo ER representa certas restrições com os quais os conteúdos de bancos de dados precisam estar de acordo. Uma restrição importante é o mapeamento de cardinalidade (ou multiplicidade de um conjunto de relacionamentos) que expressa o número de entidades ao qual outra entidade pode estar associada via um conjunto de relacionamentos. A estrutura lógica geral de um banco de dados pode ser expressa graficamente por um diagrama ER, que consiste nos seguintes componentes: Retângulosque representam conjuntos de entidades; Elipsesque representam atributos; Losangosque representam relacionamentos entre conjuntos de entidades; Linhas que ligam atributos a conjuntos de entidades e conjuntos de entidades a relacionamentos. Alguns autores chamam as linhas de arestas, em analogia às teorias de grafos e redes. Para ilustrar, considere parte de um sistema de banco de dados de uma instituição bancária, consistindo em clientes e contas que eles possuem. O diagrama ER correspondente é mostrado na figura abaixo. Modelo Orientado a Objeto Assim como o modelo ER, o modelo orientado a objeto é baseado num conjunto de objetos. Um objeto contém valores armazenados em variáveis de instância dentro do objeto. Contrariamente ao modelo orientado a registros, estes valores são eles mesmos objetos. Então, objetos contêm objetos para um nível arbitrário de encaixamento. Um objeto também possui trechos de código que operam sobre o objeto. Estes trechos de código são chamados métodos. MODELOS LÓGICOS BASEADOS EM REGISTROS Modelos lógicos baseados em registro são usados nas descrições de dados nos níveis conceitual e visual. Em comparação com os modelos de dados baseados em objetos, ambos são usados para especificar a estrutura lógica geral do banco de dados e para fornecer uma descrição de alto nível da implementação. MODELOS FÍSICOS DE DADOS Os modelos físicos de dados são usados para descrever dados no nível mais baixo. Em comparação com os modelos lógicos de dados, existem poucos modelos físicos em uso. Dois dos mais conhecidos são: Modelo unificador (unifying model); Estrutura de memória (frame memory). Os modelos físicos captam aspectos da implementação de sistemas de bancos de dados . INSTÂNCIAS E ESQUEMAS Os bancos de dados mudam através do tempo à medida que informações são inseridas ou apagadas. A coleção de informações armazenadas no banco de dados em um determinado momento é chamada de instância do banco de dados. O projeto geral do banco de dados é chamado de esquema de banco de dados. Os esquemas não mudam com freqüência. Uma analogia com os conceitos de tipos de dados, variáveis e valores nas linguagens de programação é útil aqui. Voltamos à definição do tipo de registro cliente: type cliente = record nome: string; rua: string; cidade: string; end; Note que declarando o tipo cliente, não declaramos nenhuma variável. Para declarar tais variáveis numa linguagem do tipo Pascal, escrevemos: var cliente1: cliente; O conceito de um esquema de banco de dados corresponde à noção de declaração de tipo em linguagens de programação. Uma variável de um dado tipo tem um valor particular em um determinado instante do tempo. Assim o conceito de valor de uma variável na linguagem de programação corresponde ao conceito de uma instância de um esquema de banco de dados. Os sistemas de bancos de dados possuem diversos esquemas. subdivididos de acordo com os níveis de abstração discutidos anteriormente. No nível mais baixo, está o esquema físico; no nível intermediário, o esquema conceitual; no nível mais alto, um subesquema. Em geral, os sistemas de bancos de dados suportam um esquema físico, um esquema conceitual e diversos subesquemas.