Escolar Documentos
Profissional Documentos
Cultura Documentos
Banco de Dados Orientado A Objeto
Banco de Dados Orientado A Objeto
ndice
1. 2. 3. 4. 5. 6. Introduo Conceitos Bsico Modelagem e Projeto para BDOOs Persistncia em BDOO's Transaes, Concorrncia, Recuperao, Versionamento de BDOOs Concluso e Bibliografia
Modelos de Dados Orientados a Objetos Superficialmente, pode-se dizer que orientao a objetos corresponde organizao de sistemas como uma coleo de objetos que integram estruturas de dados e comportamento. Alm desta noo bsica, a abordagem inclui um certo nmero de conceitos, princpios e mecanismos que a diferenciam das demais. Seus principais conceitos so apresentados em seguida. Abstrao a considerao apenas das propriedades comuns de um conjunto de objetos, omitindo os detalhes, utilizada com freqncia na definio de valores similares e na formao de um tipo a partir de outro, em diferentes nveis de abstrao. O uso de abstraes permite a gerao de tipos baseada em hierarquias de tipos e de relacionamentos. Os principais conceitos de abstrao utilizados em banco de dados so generalizao e agregao. A
generalizao corresponde associao " um" onde, a partir de propriedades comuns de diferentes entidades, criada uma outra entidade. O processo inverso a especializao. A agregao corresponde a associao "parte de". Objeto Os objetos so abstraes de dados do mundo real, com uma interface de nomes de operaes e um estado local que permanece oculto. As abstraes da representao e das operaes so ambas suportadas no modelo de dados orientado a objetos, ou seja, so incorporadas as noes de estruturas de dados e de comportamento. Um objeto tem um estado interno descrito por atributos que podem apenas ser acessados ou modificados atravs de operaes definidas pelo criador do objeto. Um objeto individual chamado de instncia ou ocorrncia de objeto. A parte estrutural de um objeto (em banco de dados) similar noo de entidade no modelo Entidade-Relacionamento. Identidade de Objeto Num modelo com identidade de objetos, estes tm existncia independente de seus valores correntes e dos endereos de armazenamento fsico. A identidade do objeto geralmente gerada pelo sistema. A impossibilidade de garantir a identificao de objetos exclusivamente atravs de suas propriedades estruturais e comportamentais motivou a definio de identificadores nicos de objetos, que persistem no tempo de forma independente ao estado interno do objeto. A identidade de objetos elimina as anomalias de atualizao e de integridade referencial, uma vez que a atualizao de um objeto ser automaticamente refletida nos objetos que o referenciam e que o identificador de um objeto no tem seu valor alterado. Objetos Complexos Os objetos complexos so formados por construtores (conjuntos, listas, tuplas, registros, colees, arrays) aplicados a objetos simples (inteiros, booleanos, strings). Nos modelos orientados a objetos, os construtores so em geral ortogonais, isto , qualquer construtor pode ser aplicado a qualquer objeto. No modelo relacional este no o caso, visto que s possvel aplicar o construtor de conjuntos s tuplas e o construtor de registro a valores atmicos. A manuteno de objetos complexos, independente de sua composio, requer a definio de operadores apropriados para sua manipulao como um todo, e transitivos para seus componentes. Exemplos destas operaes so: a atualizao ou remoo de um objeto e cpia profunda ou rasa. Encapsulamento O encapsulamento possibilita a distino entre a especificao e a implementao das operaes de um objeto, alm de prover a modularidade que permite uma melhor estruturao das aplicaes ditas complexas, bem como a segurana dentro do sistema. Em banco de dados se diz que um objeto est encapsulado quando o estado oculto ao usurio e o objeto pode ser consultado e modificado exclusivamente por meio das operaes a ele associadas.
Existe uma certa discusso sobre as consultas em banco de dados quando est incorporada a noo de encapsulamento: Deve-se tornar visvel apenas as operaes e deixar ocultos os dados e as implementaes ? interessante relaxar o encapsulamento apenas para as consultas ? Como deve ser realizada a otimizao de consultas em SGBDOO com encapsulamentos ? Tipo de Objetos O tipo de objeto pode ser visto como a descrio ou especificao de objetos. Um tipo possui duas partes, interface (visvel para o usurio do tipo) e implementao (visvel s para o usurio construtor do tipo). Existem vrias vantagens em se ter um sistema de tipos em um modelo de dados. Alm de modularidade e segurana, do ponto de vista da evoluo do sistema os tipos so especificaes do comportamento que podem ser compostos e modificados incrementalmente, para formar novas especificaes. Classes Um conjunto de objetos que possui o mesmo tipo (atributos, relacionamentos, operaes) pode ser agrupado para formar uma classe. A noo de classe associada ao tempo de execuo, podendo ser vista como uma representao por extenso, enquanto que o tipo uma representao intencional. Cada classe tem um tipo associado, o qual especifica a estrutura e o comportamento de seus objetos. Assim, a extenso da classe denota o conjunto dos objetos atualmente existentes na classe e o tipo prov a estrutura destes objetos. Herana Herana um mecanismo que permite ao usurio definir tipos de forma incremental, por refinamento de outros j existentes, permitindo composio de tipos em que as propriedades de um ou mais tipos so reutilizadas na definio de um novo tipo. De fato, ela corresponde a transferncia de propriedades estruturais e de comportamento de uma classe para suas subclasses. As principais vantagens de herana so prover uma maior expressividade na modelagem dos dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar especificaes e implementaes como na adaptao de mtodos gerais para casos particulares, redefinindo-os para estes, e simplificando a evoluo e a reusabilidade de esquemas de banco de dados. Tipos de Herana Os dois tipos de herana, simples e mltipla, so descritos a seguir:
q
Herana Simples: Na herana simples um certo tipo pode ter apenas um supertipo, da mesma forma uma subclasse s herda diretamente de uma nica classe. Podemos classificar esta herana em quatro subtipos: de substituio, de incluso, de restrio e de especializao. Herana Mltipla: Nesta herana um tipo pode ter supertipos e os mesmos refinamentos de herana simples. H basicamente dois tipos de conflitos referentes herana mltipla: entre o tipo e o supertipo e entre mltiplos supertipos. O primeiro pode ser resolvido dando-se prioridade
definio presente no tipo, e no a no supertipo. Com os conflitos entre mltiplos supertipos, como uma resoluo por default pode causar heranas no desejadas, a abordagem mais segura baseada na requisio explcita da interveno do usurio. Mtodos e Mensagens Um mtodo, em relao a um objeto, corresponde ao comportamento dos objetos, implementando uma operao associada a uma ou mais classes, de forma similar aos cdigos dos procedimentos usados em linguagens de programao tradicionais, que manipula o objeto ou parte deste. Cada objeto tem um certo nmero de operaes para ele definida. Para cada operao pode-se ter um ou mais mtodos de implementao associados. As mensagens so a forma mais usada para se ativar os mtodos. Num SGBDOO os objetos se comunicam e so ativados atravs de mensagens enviadas entre eles. Polimorfismo Em sistemas polimrficos uma mesma operao pode se comportar de diferentes formas em classes distintas. Como exemplo temos o operao print que ser implementada de forma diferente se o objeto correspondente for um texto ou uma imagem: dependendo do objeto teremos um tipo de impresso. Temse tambm polimorfismo quando ocorre a passagem de diferentes tios de objetos como parmetros enviados a outros objetos Um mesmo nome pode ser usado por mais de uma operao definida sobre diferentes objetos, o que caracteriza uma sobrecarga (overloading). A redefinio do operador para cada um dos tipos de objetos definidos caracteriza uma sobreposio (overriding). As operaes so ligadas aos programas em tempo de execuo caracterizando o acoplamento tardio ou late binding. Outros conceitos Finalmente h duas propriedades fundamentais para a construo de um SGBDOO: extensibilidade e completude computacional. A primeira garante que o conjunto de tipos oferecidos pelo sistema permite a definio de novos tipos e no h distino entre os tipos pr-definidos e os definidos pelo usurio. A segunda implica que a linguagem de manipulao de um banco de dados orientado a objetos pode exprimir qualquer funo computacional. ndice Anterior Prximo
Bibliografia
Khoshafian, Strag - BANCO DE DADOS ORIENTADOS A OBJETOS - IBPI press, WILEY Internet http://www.rhein-neckar.de/~cetus/software.html http://www.nce.ufrj.br/~marciosd/pfinal
Banco de Dados Orientado a Objetos 4.0 Persistncia em Banco de Dados Orientado a Objeto.
O termo persistncia raramente utilizado no contexto de banco de dados. Preferencialmente, o termo usado banco de dados, que conota o espao de objeto resiliente, concorrentemente compartilhado. A funo de um sistema de gerenciamento de banco de dados permitir o acesso e a atualizao simultneos de bancos de dados persistentes. A fim de garantir a persistncia dos dados a longo prazo, os sistemas de gerenciamento de banco de dados utilizam vrias estratgias de recuperao em caso de falhas na transao, no sistema ou no meio. H uma relao fundamental entre o compartilhamento e a persistncia simultneos em banco de dados. As atualizaes de transao devem persistir, mas, como o banco de dados persistentes ao mesmo tempo acessado e atualizado, o sistema de gerenciamento de banco de dados deve preocupar-se com a coerncia dos objetos de dados persistentes. Isso normalmente obtido por meio de estratgias de controle e recuperao concorrentes.
Nveis de Persistncia
Os dados manipulados por um banco de dados orientado a objeto podem ser transientes ou persistente. Os dados transientes s so validos dentro de um programa ou transao, eles se perdem quando o programa ou a transao termina. Os dados persistentes, por outro lado, so armazenados fora do contexto de um programa e assim sobrevivem a varias invocaes de programas. Dados persistentes normalmente consistem nos bancos de dados compartilhado, acessados e atualizados atravs de transaes. Por exemplo, banco de dados pessoais, banco de dados de inventrio e banco de dados de vendedores, contas ou itens, todos contem dados persistentes. No entanto, h vrios nveis de persistncia. Os objetos menos persistentes so aqueles criados e destrudos em procedures. Depois, h os objetos que persistentem dentro do espao de trabalho de uma transao, mas que so invalidados quando a transao termina. As transaes so normalmente executadas dentro de uma sesso. O usurio estabelece seu login e define diferentes parmetros ambientais dentro de um sesso, como caminhos, opes de exibio, janelas, etc. Se o sistema suportar o multiprocessamento, vrias transaes podero estar ativas dentro da mesma sesso de usurio ao mesmo tempo. Todas estas transaes compartilharo os objetos da sesso. No entanto, quando o usurio terminar a sesso, os objetos da sesso sero invalidados. O nico tipo de objeto que persiste atravs das transaes so objetos permanentes normalmente compartilhados por vrios usurios. Esses objetos persistem atravs de transaes, instabilizaes de sistema e ate de meio. Tecnicamente, esses so os objetos recuperveis do banco de dados.
Banco de Dados Orientado a Objetos 5.0 Transaes, Concorrncia, Recuperao e Vercionamento de BDOOs
Transaes
Uma transao um programa executado inteiramente ou ento no executado. As transaes devem mapear bancos de dados de um estado coerente para outro. Para manter a coerncia, as transaes devem passar pelo teste ACID: Atomicidade, coerncia, isolamento, e durabilidade.
Atomicidade
Como uma transao executada inteiramente ou ento no executada, ou a seqncia completa de operaes aplicada ao banco de dados ou ento nenhuma. Este recurso chama-se de Atomicidade; as transaes so atmicas.
Coerncia
Diz-se que o banco de dados coerente se todas as suas restries de integridade so satisfeitas. Pressupe-se que na execuo de uma transao, na ausncia de interferncia de outras transaes concorrentes, o banco de dados seja levado de um estado coerente para outro.
Isolamento
Como as transaes so executadas concorrentemente no mesmo banco de dados, elas devem ser isoladas das outras operaes. Do contrrio, a operao intercalada de transaes concorrente pode levar a anomalias. Assim, os SGBD suportam isolamento, que fornece segurana contra interferncias entre as transaes concorrentes.
Durabilidade
A durabilidade est relacionada capacidade do SGBO de se recuperar de falhas no sistema e no meio. As atualizaes de uma transao efetivada devem devem ser preservadas e registradas em algum meio durvel. Deve-se manter redundncia suficiente para que se reconstrua um banco de dados coerente.
Transaes aninhadas
As transaes de aplicaes de banco de dados orientadas a objetos so normalmente mais demoradas que as de aplicao comerciais convencionais. Alonga durao das transaes em aplicaes avanadas uma caracterstica das aplicaes de banco de dados da prxima gerao. Varias estratgias relacionadas longa durao das transaes foram propostas na pesquisa de banco de dados. Algumas estratgias influenciaram as implementaes de banco de dados orientado a objetos. As transaes aninhadas so utilizadas para resolver alguns problemas associados as transaes de longa durao. Um modelo de transao aninhada pode conter subtransaes, tambm chamadas de transaes-filhas. Em uma transao aninhada, todas as transaes-filhas devem ser efetivadas para que a transao de alto nvel se efetive. Cada subtransao deve ser concluda ou abortada. Tambm, em aplicaes avanadas, as tarefas normalmente envolve vrios usurios. As transaes em cooperao so utilizadas para suportar essas tarefas em conjunto.
Concorrncia
Vrios algoritmos de controle podem ser usados para garantir a capacidade de serializao das transaes e a coerncia do banco de dados. O mais notvel deles o bloqueio. Nos bancos de dados orientados a objeto, o bloqueio pode ser associado a vrios grnulos que so manipulados pelos usurios, incluindo classes, instancias e objetos complexos. Nos bancos de dados orientados a objeto, h dois aspectos de bloqueio que so relevantes para o compartilhamento concorrente de objetos: Bloqueio de Hierarquia de classe: As classes nos bancos de dados orientados a objeto so organizadas em hierarquias de herana, de modo que cada classe da hierarquia tenha uma extenso ou instancia preexistente. Por isso importante fornecer bloqueio de granularidade a essas estruturas. Por exemplo, uma superclasse poderia bloquear implicitamente todas as subclasses no mesmo modo de bloqueio. As subclasses incluem os descendentes diretos da superclasse e os descendentes de suas subclasses. Bloqueio de Objeto complexo: Os bancos de dados orientados a objetos contm objetos que podem referenciar ou incorporar outros objetos. Alem disso, alguns objetos so "valores", enquanto outros possuem identidade. Para otimizar a concorrncia na presena de modelos que envolvam objetos complexos, foram analisados vrios esquemas de bloqueio de "objetos compostos" ou de "objetos dependentes" para objetos complexos.
Recuperao
A confiabilidade e a grata recuperao de falhas so importantes recursos de um sistema de gerenciamento de banco de dados. O gerenciador de recuperao o modulo que administras as tcnicas de recuperao dessas falhas. Os trs importantes tipos de falhas que so responsabilidade do
gerenciador de recuperao so: as falhas de transao, as falhas no sistema, as falhas no meio. Uma das estruturas mais utilizadas para o gerenciamento de recuperao o log. O log utilizado para registrar e armazenar as imagens anteriores e posteriores dos objetos atualizados. A imagem anterior o estado do objeto antes da atualizao da transao, e a imagem posterior o estado do objeto aps a atualizao da transao. Quase todos os bancos de dados orientados a objeto suportam a recuperao. A maioria dos SGBDOO utiliza o logging para a recuperao do banco de dados a um estado coerente. Alguns utilizam a duplicao ou espelhamento de dados.
Vercionamento
O acesso a estados anteriores ou a estados alterados de objetos parte inerente de muitas aplicaes. Ele obtido por meio de vrias verses do mesmo objeto. O gerenciamento de verso em um banco de dados orientados a objeto consiste em ferramentas e construes que automatizam ou simplificam a construo e a organizao de verses ou configuraes. Sem essas ferramentas, caberia ao usurio organizar e manter as verses. Podemos considerar a configurao como um grupo de objetos tratados como uma unidade para bloqueio e Vercionamento. Os objetos individuais dentro da configurao podem sofrer modificaes, de modo que cada objeto pode Ter um histrico das verses. Vrios objetos dentro da configurao so atualizados em momentos diferentes e no necessariamente na mesma freqncia. ndice Anterior Prximo
Anlise Orientada a Objeto, uma abordagem passo a passo Pode-se perguntar: Porque no usar as tcnicas de anlise j estabelecidas, como a anlise estruturada. A evoluo da anlise estruturada nos mostra que h uma srie de desenvolvimentos, a programao estruturada precedida pelo projeto estruturado, que por sua vez precedido pela anlise estruturada. A anlise e o projeto estruturado so construdos no topo de noes bsicas da programao estruturada tradicional, incluindo a separao de dados e processos.
Algumas noes bsicas de programao orientada a objetos so diferentes da programao tradicional. Por instncia, objetos encapsulam ambos comportamento e estado, enquanto as linguagens tradicionais de programao deliberadamente mantm uma separao. A seguir apresentaremos uma abordagem de desenvolvimento de sistemas orientados a objetos, numa abordagem passo a passo, (3): OBA (Object Behavior Analysis) provm um modelo conceitual para um primeiro estgio na criao de uma aplicao orientada a objeto. Usando esta abordagem como um passo positivo no processo de construo, com sucesso, de um sistema flexvel orientado a objeto. A OBA tenta responder questes que a anlise tradicional de sistemas no consegue responder, e isto de uma maneira natural, encorajando a interao entre as diversas fases do desenvolvimento e com o auxlio da prototipao rpida especialmente nas fases de anlise e projeto. Uma implicao desta abordagem que analisar, projetar e implementar, no do tipo, "vamos fazer certo da primeira vez". Na prtica geralmente isso impossivel, ter a informao que se necessita para uma anlise completa, muito menos interpretar e representar todas as coisas corretamente sem interaes. Interaes controladas contribuem para clarificar e tornar mais completas as especificaes e projeto. OBA consiste de uma compreeno da aplicao e identificao dos comportamentos iniciais, definindo os objetos que exibem esses comportamentos, classificando os objetos, identificando os relacionamentos entre eles e modelando seus ciclos de vida. a) Etapa 1: Identificando os comportamentos Para compreender o que a aplicao far, primeiro entrevista-se o usurio para a aplicao pretendidada observando ento a ao para ver o que ela far, quem ou o qu interagir com o sistema , em que ordem ocorrer, e quais as diferentes aes tomadas. O ponto principal uma lista dos desejos necessrios para o sistema analisado, o mais alto nvel do comportamento define as responsabilidades do sistema. A sada desta etapa uma lista dos comportamentos desejados do sistema e uma lista de suas propriedades visveis,bem como de "scripts". b) Etapa 2: Definindo os objetos Uma vez definidos os comportamentos iniciais necessita-se determinar a sua performance. Encontrar os objetos um passo para compreender a sua performance. Imediatamente v-se quem ou o que responsavel por um comportamento particular.
Cartes de modelagem, usados nesta etapa, so pequenos cartes indexados com os termos:"nome", "responsabilidade" e "colaboradores",escrito neles. Nesses cartes escreve-se o comportamento do sistema (responsabilidades), o que ou quem responsvel por um comportamento em particular, to bem quanto para padres de comportamento (nome) e quem ou o que este agente responsvel interage (colaboradores). Os objetos de aplicao so compostos desses objetos concretos, conceitos, processos e eventos que exibem comportamentos significativos. A sada da etapa 2 uma lista de objetos, os quais relatados em grupos de comportamento e propriedades visveis. Pode ser necessrio fazer esta etapa mais de uma vez para atualizar a lista de objetos (p. ex.: adicionar uma classe de objetos). c) Etapa 3: Classificando os objetos Neste caso, classificao significa agrupar objetos de acordo com alguma similaridade de comportamento (funo) e estado (forma). Classificar objetos primariamente pelo comportamento a chave da OBA. Para isso, deve ser visto comportamentos similares em diferentes objetos. A sada da etapa 3 um diagrama de relacionamento hierrquico entre os objetos, baseados na forma abstrata usando o critrio de comportamento similar. Uma importante tarefa no mundo da orientao a objeto distinguir o abstrato a partir do especfico. OBA inicia o projeto com o p direito, por auxiliar na localizao de conceitos que sero usados para ambas classes, abstrato e concreto durante o projeto e implementao. d) Etapa 4: Identificando os relacionamentos A etapa 4 envolve um desenho de um esboo preliminar dos objetos em relao uns com os outros. Usando esse esboo, to bem quanto um "script" e os cartes de modelagem, pode -se criar uma tabela que clarifica os relacionamentos que cada objeto tem uns com os outros. Para OBA, necessita-se obter uma descrio,a mais clara possvel, em termos de linguagem natural, dos relacionamentos entre os objetos. Ento simplifica-se essas descries de linguagens. De outro modo, reduzindo uma descrio simplificada em linguagem natural para os subconjuntos dos relacionamentos implementveis em OOL, parte da fase de projeto e no da fase de anlise. e) Etapa 5: Modelando o Processo Necessita-se para determinar quais objetos iniciam atividades e identificar qual a sequencia das atividades, para isso so usados os "scripts" desenvolvidos na etapa 1 para iniciar o modelo de aplicao. Pode-se especificar o ciclo de vida dos objetos e seus "status" em diferentes partes do ciclo.
f) A Anlise Final: O resultado da OBA so as especificaes das necessidades, escrita em termos de comportamento requerido, que delinea os objetos primrios como eles so organizados. Esta especificao inclui objetos superordenados a partir de um agrupamento por comportamento e objetos subordenados. O comportamento primrio e estado da cada objeto listado, bem como seus relacionamentos dos objetos e as sequncias de atividades. Os "scripts" produzidos na OBA so especialmente usados no detalhamento de como trabalhar a interface com o usurio. Com o uso da OBA para anlise de um sistema orientado a objeto, obtm-se uma especificao do comportamento que enfatiza os aspectos da alta reusabilidade do sistema, que , os protocolos de comportamento e os agrupamentos hierrquicos dos objetos de acordo com o protocolo. Uma anlise cuidadosa, focando as abstraes comportamentais, promovem uma reduo no cdigo,por calar o caminho para uma boa construo hierrquica e hereditariedade e o seu uso prudente pode ajudar a produzir uma clara e compreensvel estrutura de aplicao orientada a objeto.
informaes, os objetos correspondem s entidades de dados utilizadas. b) Para cada objeto so definidas as funes ou servios que dever permitir, direta ou indiretamente, o atendimento aos requisitos estabelecidos. Todos os servios correspondentes a um mesmo objeto devem ser integrados e estruturados em um nico mdulo, estabelecendo-se assim a funcionalidade do objeto. c) Um objeto, atravs de seus servios, pode colaborar com outros objetos. Esta colaborao se processa atravs da troca de mensagens entre os objetos cliente e servidor. a) O objeto pode tambm herdar algumas funcionalidades correspondentes a seu objeto "pai", o qual deve representar, conceitualmente, uma entidade mais genrica. Entre as principais vantagens oferecidas pelo mtodo do projeto orientado por objeto temos: a) Fornece regras precisas para a modularizao do sistema. b) Desenvolvimento de uma arquitetura mais estvel, uma vez que se estrutura com base no modelo de dados utilizado, o qual apresenta pouca vulnerabilidade a mudanas na funcionalidade do sistema. c) Alto grau de reusabilidade das rotinas desenvolvidas. d) Maior facilidade de transio da fase de anlise para a fase de projeto.
CONCLUSES
A orientao a objetos (2) uma mudana cultural, muito mais do que uma mudana tecnolgica, ela um paradigma, uma revoluo industrial do software baseada na reusabilidade e intercambialidade entre as partes que alterar o universo de software to fortemente quanto a revoluo industrial alterou a manufatura. O paradigma muda das linguagens procedurais para as linguagens orientadas a objeto, com o direcionamento para ambientes de alto nvel como o Smalltalk. Do mesmo modo as metodologias mudam das estruturadas para as orientadas a objetos, no podendo haver uma continuidade nas tcnicas estruturadas existentes, confirmando (1), "os mtodos estruturados No podem ser objetificados". Grandes organizaes mudam lentamente, velhas metodologias, quando h, so difceis de mudar o no entanto se requer uma mudana radical na maneira de como sistemas sero desenvolvidos a partir de agora, isto , orientados a objeto e com auxlio de CASE. Os anos 90 sero de gradual aceitao da orientao a objetos e no podendo tomar por base antigas metodologias. Orientao a objetos promete muito mais do que "apontar e clicar" a interface de janelas, e com a popularizao das arquiteturas abertas, redes distribudas, CASE e ambientes grficos o seu destino est definido. ndice Anterior Prximo