WIXLIB

Introdução a Banco de DadosO.K. Takai; I.C.Italiano; J.E. Ferreira.7Figura 1.1 - Diagrama de estrutura de árvore Cliente - Conta Corrente1.1.2 Modelo em RedeO modelo em redes surgiu como uma extensão ao modelo hierárquico, eliminando o conceitode hierarquia e permitindo que um mesmo registro estivesse envolvido em várias associações.No modelo em rede, os registros são organizados em grafos onde aparece um único tipo deassociação (set) que define uma relação 1:N entre 2 tipos de registros: proprietário e membro.Desta maneira, dados dois relacionamentos 1:N entre os registros A e D e entre os registros Ce D é possível construir um relacionamento M:N entre A e D. O gerenciador Data Base TaskGroup (DBTG) da CODASYL (Committee on Data Systems and Languages) estabeleceu umanorma para este modelo de banco de dados, com linguagem própria para definição emanipulação de dados. Os dados tinham uma forma limitada de independência física. A únicagarantia era que o sistema deveria recuperar os dados para as aplicações como se elesestivessem armazenados na maneira indicada nos esquemas. Os geradores de relatórios daCODASYL também definiram sintaxes para dois aspectos chaves dos sistemas gerenciadoresde dados: concorrência e segurança. O mecanismo de segurança fornecia uma facilidade naqual parte do banco de dados (ou área) pudesse ser bloqueada para prevenir acessossimultâneos, quando necessário. A sintaxe da segurança permitia que uma senha fosseassociada a cada objeto descrito no esquema. Ao contrário do Modelo Hierárquico, em quequalquer acesso aos dados passa pela raiz, o modelo em rede possibilita acesso a qualquer nóda rede sem passar pela raiz. No Modelo em Rede o sistema comercial mais divulgado é o CAIDMS da Computer Associates. O diagrama para representar os conceitos do modelo em redesconsiste em dois componentes básicos: Caixas, que correspondem aos registros e Linhas, quecorrespondem às associações. A Figura 1.2 ilustra um exemplo de diagrama do modelo emrede.Figura 1.2 - Diagrama de estrutura de dados Cliente - Conta Corrente

Introdução a Banco de DadosO.K. Takai; I.C.Italiano; J.E. Ferreira.8Estes dois modelos: Hierárquico e Rede são Orientados a Registros, isto é, qualquer acesso àbase de dados – inserção, consulta, alteração ou remoção – é feito em um registro de cadavez.1.1.3 Modelo RelacionalO modelo relacional apareceu devido às seguintes necessidades: aumentar a independênciade dados nos sistemas gerenciadores de banco de dados; prover um conjunto de funçõesapoiadas em álgebra relacional para armazenamento e recuperação de dados; permitirprocessamento ad hoc1. O modelo relacional, tendo por base a teoria dos conjuntos e álgebrarelacional, foi resultado de um estudo teórico realizado por CODD[1]2. O Modelo relacionalrevelou-se ser o mais flexível e adequado ao solucionar os vários problemas que se colocamno nível da concepção e implementação da base de dados. A estrutura fundamental do modelorelacional é a relação (tabela). Uma relação é constituída por um ou mais atributos (campos)que traduzem o tipo de dados a armazenar. Cada instância do esquema (linha) é chamada detupla (registro). O modelo relacional não tem caminhos pré-definidos para se fazer acesso aosdados como nos modelos que o precederam. O modelo relacional implementa estruturas dedados organizadas em relações. Porém, para trabalhar com essas tabelas, algumas restriçõesprecisaram 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 integridade de junções de relações. A Figura 1.3, abaixo, trazexemplos de tabelas sob o modelo relacional.Figura 1.3 Tabelas do modelo relacional Cliente - Conta Corrente1.1.4 Modelo Orientado a ObjetosOs bancos de dados orientados a objeto começaram a se tornar comercialmente viáveis emmeados de 1980. A motivação para seu surgimento está em função dos limites dearmazenamento e representação semântica impostas no modelo relacional. Alguns exemplossão os sistemas de informações geográficas (SIG), os sistemas CAD e CAM, que são maisfacilmente construídos usando tipos complexos de dados. A habilidade para criar os tipos dedados necessários é uma característica das linguagens de programação orientadas a objetos.Contudo, estes sistemas necessitam guardar representações das estruturas de dados queutilizam no armazenamento permanente. A estrutura padrão para os bancos de dadosorientados a objetos foi feita pelo Object Database Management Group (ODMG). Esse grupo é1Processamento dedicado, exclusivo.Codd era investigador da IBM. O modelo foi apresentado num artigo publicado em 1970, mas só nosanos 80 o modelo foi implementado.2

Introdução a Banco de DadosO.K. Takai; I.C.Italiano; J.E. Ferreira.9formado por representantes dos principais fabricantes de banco de dados orientados a objetodisponíveis comercialmente. Membros do grupo têm o compromisso de incorporar o padrão emseus produtos. O termo Modelo Orientado a Objetos é usado para documentar o padrão quecontém a descrição geral das facilidades de um conjunto de linguagens de programaçãoorientadas a objetos e a biblioteca de classes que pode formar a base para o Sistema deBanco de Dados. Quando os bancos de dados orientados a objetos foram introduzidos,algumas das falhas perceptíveis do modelo relacional pareceram ter sido solucionadas comesta tecnologia e acreditava-se que tais bancos de dados ganhariam grande parcela domercado. Hoje, porém, acredita-se que os Bancos de Dados Orientados a Objetos serãousados em aplicações especializadas, enquanto os sistemas relacionais continuarão asustentar os negócios tradicionais, onde as estruturas de dados baseadas em relações sãosuficientes. O diagrama de classes UML serve geralmente como o esquema para o modelo dedados orientado a objetos. Observe o exemplo da Figura 1.4, e compare as diferenças com omodelo anterior.Figura 1.4 - Diagrama UML Cliente - Conta Corrente1.1.5 Sistemas Objeto-RelacionaisA área de atuação dos sistemas Objeto-Relacional tenta suprir a dificuldade dos sistemasrelacionais convencionais, que é o de representar e manipular dados complexos, visando sermais representativos em semântica e construções de modelagens. A solução proposta é aadição de facilidades para manusear tais dados utilizando-se das facilidades SQL (StructuredQuery Language) existentes. Para isso, foi necessário adicionar: extensões dos tipos básicosno contexto SQL; representações para objetos complexos no contexto SQL; herança nocontexto SQL e sistema para produção de regras.1.2Arquiteturas de Banco Dados1.2.1 IntroduçãoAtualmente, devem-se considerar alguns aspectos relevantes para atingir a eficiência e aeficácia dos sistemas informatizados desenvolvidos, a fim de atender seus usuários nos maisvariados 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 derecursos, entre outros. Tais aspectos são:a) Os projetos Lógico e Funcional do Banco de Dados devem ser capazes de prever o volumede informações armazenadas a curto, médio e longo prazo. Os projetos devem ter umagrande capacidade de adaptação para os três casos mencionados;b) Deve-se ter generalidade e alto grau de abstração de dados, possibilitando confiabilidade eeficiência no armazenamento dos dados e permitindo a utilização de diferentes tipos degerenciadores de dados através de linguagens de consultas padronizadas;c) Projeto de uma interface ágil e com uma "rampa ascendente" para propiciar aprendizadosuave ao usuário, no intuito de minimizar o esforço cognitvo;

Introdução a Banco de DadosO.K. Takai; I.C.Italiano; J.E. Ferreira.10d) Implementação de um projeto de interface compatível com múltiplas plataformas (UNIX,Windows NT, Windows Workgroup, etc);e) Independência de Implementação da Interface em relação aos SGBDs que darãocondições às operações de armazenamento de informações (ORACLE, SYSBASE,INFORMIX, PADRÃO XBASE, etc).f)Conversão e mapeamento da diferença semântica entre os paradigmas utilizados nodesenvolvimento de interfaces (Imperativo (ou procedural), Orientado a Objeto, Orientado aevento), servidores de dados (Relacional) e programação dos aplicativos (Imperativo,Orientado a Objetos).1.2.2 ArquiteturasAs primeiras arquiteturas usavam mainframes para executar o processamento principal e detodas as funções do sistema, incluindo os programas aplicativos, programas de interface com ousuário, bem como a funcionalidade dos SGBDs. Esta é a razão pela qual a maioria dosusuá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 paraos terminais de visualização, conectados a ele por redes de comunicação. Como os preços dohardware foram decrescendo, muitos usuários trocaram seus terminais por computadorespessoais (PC) e estações de trabalho. No começo os SGBDs usavam esses computadores damesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda suafuncionalidade, execução de programas aplicativos e processamento da interface do usuárioeram executados em apenas uma máquina. Gradualmente, os SGBDs começaram a explorar adisponibilidade do poder de processamento no lado do usuário, o que levou à arquiteturacliente-servidor.A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computação onde umgrande número de PCs, estações de trabalho, servidores de arquivos, impressoras, servidoresde 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 demáquinas clientes, ou servidores de impressão que podem estar conectados a váriasimpressoras; assim, quando se desejar imprimir algo, todas as requisições de impressão sãoenviadas a este servidor. As máquinas clientes disponibilizam para o usuário as interfacesapropriadas para utilizar esses servidores, bem como poder de processamento para executaraplicações locais. Esta arquitetura se tornou muito popular por algumas razões. Primeiro, afacilidade de implementação dada a clara separação das funcionalidades e dos servidores.Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples sãodelegadas às máquinas clientes mais baratas. Terceiro, o usuário pode executar uma interfacegráfica que lhe é familiar, ao invés de usar a interface do servidor. Desta maneira, a arquiteturacliente-servidor foi incorporada aos SGBDs comerciais. Diferentes técnicas foram propostaspara se implementar essa arquitetura, sendo que a mais adotada pelos SistemasGerenciadores de Banco de Dados Relacionais (SGBDRs) comerciais é a inclusão dafuncionalidade de um SGBD centralizado no lado do servidor. As consultas e a funcionalidadetransacional permanecem no servidor, sendo que este é chamado de servidor de consulta ouservidor de transação. É assim que um servidor SQL é fornecido aos clientes. Cada cliente temque formular suas consultas SQL, prover a interface do usuário e as funções de interfaceusando uma linguagem de programação. O cliente pode também se referir a um dicionário dedados o qual inclui informações sobre a distribuição dos dados em vários servidores SQL, bemcomo os módulos para a

Relacional de Domínio. No Capítulo 8, a linguagem SQL - linguagem de consulta comercial mais difundida para o modelo relacional - é introduzida, por meio de sua teoria e exemplos práticos. O Capítulo 9 trata de projeto de banco de dados, normalização e dependências funcionais entre os dados.