BRPI0709108A2 - arquitetura de mapeamento com manutenção de visualização incremental - Google Patents

Abstract

ARQUITETURA DE MAPEAMENTO COM MANUTENçãO DE VISUALIZAçãO INCREMENTAL. é fornecida uma arquitetura de acesso a dados que inclui uma arquitetura de mapeamento para mapear dados como podem ser utilizados por uma aplicação em dados como persistido em um banco de dados. A arquitetura de mapeamento faz uso de dois tipos de visualizações de mapeamento - uma visualização de consulta que ajuda a traduzir consultas e uma visualização de atualização que ajuda a traduzir atualizações. Manutenção de visualização incremental pode ser utilizada para traduzir dados entre a aplicação e banco de dados.

Description

"ARQUITETURA DE MAPEAMENTO COM MANUTENÇÃO DE VISUALIZAÇÃOINCREMENTAL"

ANTECEDENTES

A junção de aplicações e bancos de dados é um problema que existe há muitotempo. Em 1996, Carey e DeWitt delinearam porque muitas tecnologias, incluindo bancosde dados orientados para objetos e linguagens de programação persistentes, não obtiveramaceitação ampla devido a limitações em processamento de consulta e atualização, capaci-dade de transmissão de transação, e capacidade de escalonamento. Especularam que ban-cos de dados relacionais-objetos (O/R) dominariam em 2006. Realmente, os sistemas debancos de dados DB2® e Oracle® incluem uma camada de objeto incorporada que utilizaum mapeamento O/R com ligação física no topo de um motor relacionai convencional. En-tretanto, as características O/R oferecidas por esses sistemas parecem ser raramente utili-zadas para armazenagem de dados de empresa, com a exceção de tipos de dados espaci-ais e de multimeios. Entre os motivos estão independência do vendedor e dados, o custo demigrar de bancos de dados de legado, dificuldades de escalonar quando a lógica comercialroda dentro do banco de dados em vez de nível médio, e integração insuficiente com lingua-gens de programação.

Desde meados de 90, camadas de mapeamento de dados do lado do cliente adqui-riram popularidade, fomentado pelo crescimento de aplicações na Internet. Uma função es-sencial de uma tal camada é fornecer uma visualização atualizável que expõe um modelo dedados alinhado estreitamente com o modelo de dados de aplicação, acionado por um ma-peamento explícito. Muitos produtos comerciais e projetos de fonte aberta emergiram paraoferecer essas capacidades. Virtualmente toda estrutura de emprega provê uma camada depersistência do lado do cliente (por exemplo, EJB em J2EE). A maioria das aplicações co-mercial embaladas, como aplicações CRM e ERP, incorpora interfaces de acesso de dadosde propriedade (por exemplo, BAPI em SAP R/3).

Uma estrutura de Mapeamento Relacional-objeto (ORM) de fonte aberta ampla-mente usada para Java® é Hibernate®. Suportam um número de cenários de mapeamentode herança, controle de concorrência otimista, e serviços de objeto abrangentes. O maisrecente release de Hibernate se conforma com o padrão EFB 3.0, que inclui a Linguagem deConsulta de Persistência Java. No lado comercial, ORMs populares incluem Oracle To-pLink® e LLBLGen®. O último roda na plataforma .NET. Esses e outros ORMS são ajusta-damente acoplados aos modelos de objeto de suas linguagens de programação alvo.

ΒΕΑ® introduziu recentemente um novo produto de middleware denominado Aqua-Logic Data Services Platform® (ALDSP). Utilizam Esquemas XML para modelar dados deaplicação. Os dados XML são montados utilizando Xquery a partir de bancos de dados eserviços de rede. O runtime de ALDSP suporta consulta através de múltiplas fontes de da-dos e executa otimização de consulta do lado de cliente. As atualizações são executadaspor atualizações de visualização em visualizações Xquery. Se uma atualização não tiveruma tradução única, o desenvolvedor necessita anular a lógica de atualização utilizandocódigo imperativo. A superfície de programação de ALDSP se baseia em objetos de dadosde serviço (SDO).

As camadas de mapeamento do lado de cliente hoje em dia oferecem graus am-plamente variáveis de capacidade, robustez, e custo total de propriedade. Tipicamente, omapeamento entre os artefatos de banco de dados e aplicação utilizados por ORMs temsemântica vaga e aciona raciocínio caso a caso. Uma implementação acionada por cenáriolimita a gama de mapeamentos suportados e freqüentemente fornece um runtime frágil queé difícil de estender. Poucas soluções de acesso de dados alavancam técnicas de transfor-mação de dados desenvolvidas pela comunidade de banco de dados, e freqüentemente sebaseiam em soluções ad hoc para tradução de consulta e atualização.

A pesquisa de banco de dados contribuiu com muitas técnicas poderosas que po-dem ser alavancadas para construir camadas de persistência. E ainda assim, há lacunassignificativas. Entre as mais críticas está suportar atualizações através de mapeamentos.

Em comparação com consultas, as atualizações são muito mais difíceis de se lidar com vistoque necessitam de conservar consistência de dados através de mapeamentos, podem acio-nar regras comerciais e assim por diante. Como conseqüência, sistemas de bancos de da-dos comerciais e produtos de acesso a dados oferecem suporte muito limitado para visuali-zações atualizáveis. Recentemente, os pesquisadores se voltaram para abordagens alterna-tivas, como transformações bidirecionais.

Tradicionalmente, a modelagem conceptual foi limitada ao desenho de banco dedados e aplicação, engenharia inversa e tradução de esquemas. Muitas ferramentas de de-senho utilizam UML. Somente recentemente a modelagem conceptual começou a penetrarem soluções de mapeamento de dados de resistência de indústria. Por exemplo, o conceitode entidades e relações alisa tanto ALDSP como EJB 3.0. ALDSP cobre relações do estiloE-R no topo de dados XML do tipo complexo, enquanto EJB 3.0 permite especificar relaçõesentre objetos utilizando anotações de classe.

Técnicas de mapeamento de esquema são utilizadas em muitos produtos de inte-gração de dados, como ferramentas Microsoft® BizTaIk Server®, IBM® Rational Data Archi-tect® e ETL®. Esses produtos permitem que desenvolvedores projetem transformações dedados ou compilem as mesmas a partir de mapeamentos para traduzir mensagens e-commerce ou carregar depósitos de dados.

SUMÁRIO

Sistemas, métodos e meios legíveis por computador são fornecidos para implemen-tação e uso de uma arquitetura de acesso de dados que inclui uma arquitetura de mapea-mento para mapear dados como podem ser utilizados por uma aplicação em dados comopersistido em um banco de dados. Em uma modalidade, a arquitetura de mapeamento fazuso de dois tipos de visualizações de mapeamento - uma visualização de consulta que aju-da a traduzir consultas e uma visualização de atualizar que ajuda a traduzir atualizações. A manutenção de visualização incrementai pode ser utilizada para traduzir dados entre a apli-cação e banco de dados. Aspectos e modalidades adicionais são descritas abaixo.

BREVE DESCRIÇÃO DOS DESENHOS

Os sistemas e métodos para mapear arquitetura com manutenção de visualizaçãoincrementai, de acordo com a presente invenção, são descritos adicionalmente com referên-cia aos desenhos em anexo, nos quais:

A figura 1 ilustra uma arquitetura de uma Estrutura de Entidade exemplar comoconsiderado aqui.

A figura 2 ilustra um esquema relacionai exemplar.

A figura 3 ilustra um esquema de Modelo de Dados de Entidade (EDM) exemplar.

A figura 4 ilustra um mapeamento entre um esquema de entidade (esquerda) e umesquema de banco de dados (direita).

A figura 5 ilustra um mapeamento representado em termos de consultas em um es-quema de entidade e um esquema relacionai.

A figura 6 ilustra visualizações bidirecionais - as visualizações de consulta e atuali-zação - geradas pelo compilador de mapeamento para o mapeamento na figura 5.

A figura 7 ilustra um processo para alavancar algoritmos de manutenção de visuali-zação materializado para propagar atualizações através de visualizações bidirecionais.

A figura 8 ilustra uma interface de usuário designer de mapeamento.

A figura 9 ilustra compilação de um mapeamento especificado em uma Linguagemde Especificação de mapeamento (MSL) para gerar Visualizações de Consulta e atualiza-ção.

A figura 10 ilustra processamento de atualização.

A figura 11 ilustra partes lógicas exemplares de um mapeador Relacionai de Objeto(OR).

A figura 12 ilustra gerar uma Visualização de Consulta e Atualização pela Platafor-ma de Dados de entidade (EDP) ao processar um mapeamento especificado em uma espe-cificação MSL.

A figura 13 ilustra o uso de um QMView em uma tradução de consulta.

A figura 14 ilustra o uso de um UMView em uma tradução de atualização.

A figura 15 ilustra manipulação de runtime e tempo de compilar das visualizaçõesde mapeamento.

A figura 16 ilustra interação de vários componentes em um processo de compilaçãode visualização.

A figura 17 ilustra uma arquitetura de Tradutor de Consulta EDP (EQT). O EQT uti-liza metadados de mapeamento para traduzir consultas a partir do espaço EDM/objeto emespaço de banco de dados.

A figura 18 ilustra a composição de uma variedade de expressões delta para obteruma expressão delta para tabelas em termos de expressões delta para objetos.

DESCRIÇÃO DETALHADA

Nova arquitetura de acesso a dados

Em uma modalidade, a inovação pode ser implementada em e incorpora aspectosde uma nova arquitetura de acesso a dados - uma "Estrutura de entidade" - como descritonessa seção. Um exemplo de uma tal Estrutura de Entidade é a arquitetura de acesso adados ADO.NET vNEXT® desenvolvida por MICROSOFT® Corporation. O que se segue éuma descrição geral da arquitetura de acesso a dados ADO.NET vNEXT juntamente commuitos detalhes específicos de implementação que não devem ser considerados necessá-rios para prática da invenção.

VISÃO GERAL

Aplicações de servidor-cliente tradicionais relegam operações de consulta e persis-tência em seus dados aos sistemas de banco de dados. O sistema de banco de dados ope-ra em dados na forma de linhas e tabelas, enquanto a aplicação opera em dados em termosde construções de linguagem de programação de nível mais elevado (classes, estruturas,etc.). O descasamento de impedância nos serviços de manipulação de dados entre a aplica-ção e o nível de banco de dados era problemático mesmo em sistemas tradicionais. Com oadvento de arquiteturas orientadas para serviço (SOA), servidores de aplicação e aplicaçõesde multi-níveis, a necessidade de serviços de manipulação e acesso a dados que são bemintegrados com ambientes de programação e podem operar em qualquer nível aumentoutremendamente.

A Estrutura de Entidade ADO.NET da Microsoft é uma plataforma para programa-ção contra dados que eleva o nível de abstração a partir do nível relacionai para o nível con-ceptual (entidade), e desse modo reduz significativamente o descasamento de impedânciapara aplicações e serviços cêntricos em dados. Os aspectos da Estrutura de Entidade, aarquitetura geral do sistema, e as tecnologias subjacentes são descritas abaixo.

INTRODUÇÃO

Aplicações modernas exigem serviços de gerenciamento de dados em todos os ní-veis. Necessitam manipular formas cada vez mais ricas de dados que incluem não somentedados comerciais estruturados (como Clientes e Pedidos), como também conteúdo semi-estruturado e não estruturado como e-mail, calendários, arquivos e documentos. Essas apli-cações necessitam integrar dados a partir de múltiplas fontes de dados bem como coletar,limpar, transformar e armazenar esses dados para permitir um processo de tomada de deci-são mais ágil. Os desenvolvedores dessas aplicações necessitam de ferramentas de aces-so, programação e desenvolvimento de dados para aumentar sua produtividade. Emborabancos de dados relacionais tenham se tornado a armazenagem de facto para a maioria dosdados estruturados, tende a haver um descasamento - o problema bem conhecido de des-casamento de impedância - entre o modelo de dados (e capacidades) exposto por tais ban-cos de dados, e as capacidades de modelagem necessitadas pelas aplicações.

Dois outros fatores também desempenham um papel importante no desenho do sis-tema de empresa. Primeiramente, a representação de dados para aplicações tende a evoluirdiferentemente daquele dos bancos de dados subjacentes. Em segundo lugar, muitos sis-temas são compostos de diferentes back-ends de banco de dados com graus de capacidadediferentes. A lógica de aplicação no nível médio é responsável por transformações de dadosque reconciliam essas diferenças e apresentando uma visualização mais uniforme de dados.

Essas transformações de dados se tornam rapidamente complexas. A implementação dasmesmas, especialmente quando os dados subjacentes necessitam ser atualizáveis, é umproblema difícil e acrescenta complexidade à aplicação. Uma porção significativa de desen-volvimento de aplicação - até 40% em alguns casos - é dedicada a gravar lógica de acessode dados sob encomenda para resolver esses problemas.

Os mesmos problemas existem, e não são menos graves, para serviços cêntricosem dados. Serviços convencionais como consulta, atualizações e transações foram imple-mentados no nível de esquema lógico (relacionai). Entretanto, a grande maioria de serviçosmais novos, como replicação e análise, operam melhor em artefatos tipicamente associadosa um nível mais elevado, modelo de dados conceptual. Por exemplo, Replicação SQLSERVER® inventou uma estrutura denominada "registro lógico" para representar uma formalimitada de entidade. Similarmente, Serviços de Reportar Servidor SQL constroem relatóriosno topo de um modelo de dados semelhante à entidade denominado linguagem de modelode dados semânticos (SDML). Cada um desses serviços tem ferramentas sob encomendapara definir entidades conceptuais e mapear as mesmas em tabelas relacionais - uma enti-dade Cliente necessitará, portanto ser definida e mapeada em um modo para replicação,outro modo para reportar construção, ainda outro modo para outros serviços de análise eassim por diante. Como com aplicações, cada serviço termina tipicamente construindo umasolução sob encomenda para esse problema, e conseqüentemente, há duplicação de códigoe interoperabilidade limitada entre esses serviços.

Tecnologias de mapeamento de objeto-para-relacional (ORM) como HIBERNATE®e ORACLE TOPLINK® são uma alternativa popular para moldar lógica de acesso a dados.Os mapeamentos entre o banco de dados e aplicações são expressos em uma estruturasob encomenda, ou através de anotações de esquema. Essas estruturas sob encomendapodem parecer similares a um modelo conceptual; entretanto, as aplicações não podemprogramar diretamente contra esse modelo conceptual. Embora os mapeamentos forneçamum grau de independência entre o banco de dados e a aplicação, o problema de manipularmúltiplas aplicações com visualizações levemente diferentes dos mesmos dados (por exem-pio, considere duas aplicações que desejam olhar projeções diferentes de uma entidade deCliente), ou das necessidades de serviços que tendem a ser mais dinâmicos (técnicas degeração de classe a priori não funcionam bem para serviços de dados, uma vez que o ban-co de dados subjacente pode evoluir mais rápido) não são bem endereçadas por essas so-luções.

A Estrutura de Entidade ADO.NET é uma plataforma para programar contra dadosque reduz, significativamente, o descasamento de impedância para aplicações e serviçoscêntricos em dados. Difere de outros sistemas e soluções pelo menos nos seguintes aspec-tos:

1. A Estrutura de entidade define um modelo de dados conceptual rico (o Modelo dedados de entidade, ou o EDM), e uma nova linguagem de manipulação de dados (Entidade

SQL) que opera em ocorrências desse modelo. Como SQL, o EDM é baseado em valor, istoé, o EDM define os aspectos estruturais de entidades, e não os comportamentos (ou méto-dos).

2. Esse modelo é tornado concreto por um runtime que inclui um motor de mapea-mento de middleware que suporta mapeamentos bidirecionais poderosos (EDM - relacionai)para consultas e atualizações.

3. Aplicações e serviços podem programar diretamente contra a camada conceptualbaseada em valor, ou contra abstrações de objeto específicas de linguagem de programa-ção que podem ser dispostas sobre a abstração conceptual (entidade), fornecendo funciona-

Iidade semelhante a ORM. Os requerentes acreditam que uma abstração conceptual EDMbaseada em valor é uma base mais flexível para compartilhar dados entre aplicações e ser-viços cêntricos em dados do que objetos.

4. Finalmente, a Estrutura de Entidade alavanca as novas tecnologias de LanguageIntegrated Query (LINQ) da Microsoft que estendem linguagens de programação nativamen-

te com expressões de consulta para reduzir ainda mais, e para alguns cenários eliminar to-talmente, o descasamento de impedância para aplicações.

A Estrutura de Entidade ADO.NET pode ser incorporado em uma estrutura maiorcomo a Estrutura Microsoft.NET.

O resto dessa descrição de uma arquitetura de acesso a dados, no contexto deuma modalidade de Estrutura de Entidade ADO.NET, é organizada como a seguir. A seção"motivação" provê motivação adicional para a Estrutura de Entidade. A seção "Estrutura deEntidade" apresenta a Estrutura de Entidade e o Modelo de Dados de entidade. A seção"Padrões de programação" descreve padrões de programação para a Estrutura de Entidade.A seção "Serviços de objeto" delineia o módulo Serviços de Objeto. A seção "Mapeamento"focaliza no componente mapeamento da Estrutura de Entidade, enquanto as seções "Pro-cessamento de consulta" e processamento de atualização" explicam como as consultas eatualizações são tratadas. Os "Metadados" e "Ferramentas" descrevem o subsistema demetadados e os componentes de ferramentas da Estrutura de Entidade.

MOTIVAÇÃO

Essa seção discute por que uma camada de modelagem de dados de nível maiselevado se tornou essencial para aplicações e serviços cêntricos em dados.

Níveis de informação em aplicações de dados

As metodologias de modelagem de informações dominantes hoje em dia para pro-duzir desenhos de banco de dados fatoram um modelo de informação em quatro níveis prin-cipais: Físico, Lógico (relacionai), Conceptual, e Programação/apresentação.

O modelo físico descreve quantos dados são representados em recursos físicoscomo memória, fio ou disco. O vocabulário de conceitos discutido nessa camada inclui for-matos de registro, partições de arquivo e grupos, pilhas e índices. O modelo físico é tipica-mente invisível à aplicação - alterações no modelo físico não devem causar impacto na ló-gica de aplicação, porém podem causar impacto sobre o desempenho de aplicação.

O modelo de dados lógicos é um modelo de informações completas e precisas dodomínio alvo. O modelo relacionai é a representação de escolha para a maioria dos modelosde dados lógicos. Os conceitos discutidos no nível lógico incluem tabelas, linhas, limitaçõeschave-primária/chave-estranha, e normalização. Embora a normalização ajude a obter con-sistência de dados, concurrency aumentada, e melhor desempenho de OLTP, também in-troduz desafios significativos para aplicações. Dados normalizados no nível lógico são fre- qüentemente demasiadamente fragmentos e a lógica de aplicação necessita montar linhas apartir de múltiplas tabelas em entidades de nível mais elevadas que lembram mais estreita-mente os artefatos do domínio de aplicação.

O modelo conceptual captura as entidades de informação de núcleo a partir do do-mínio de problema e suas relações. Um modelo conceptual bem conhecido é o Modelo deRelação-Entidade introduzido por Peter Chen em 1976. UML é um exemplo mais recente deum modelo conceptual. A maioria das aplicações envolve uma fase de desenho conceptualprematura no ciclo de vida de desenvolvimento de aplicação. Infelizmente, entretanto, osdiagramas de modelo de dados conceptuais, ficam "pregados em uma parede" crescendocada vez mais separada a partir da realidade da implementação de aplicação com o tempo.Um objetivo importante da Estrutura de Entidade é fazer o modelo de dados conceptual (in-corporado pelo Modelo de Dados de entidade descrito na seção seguinte) uma abstraçãoprogramável, concreta da plataforma de dados.O modelo programação/apresentação descreve como as entidades e relações domodelo conceptual necessitam ser manifestas (apresentadas) em diferentes formas combase na tarefa em mão. Algumas entidades necessitam ser transformadas em objetos delinguagem de programação para implementar lógica comercial de aplicação; outras necessi-tam ser transformadas em fluxos XML para invocações de serviço de rede; ainda outras ne-cessitam ser transformadas em estruturas em-memória como listas ou dicionários para finsde ligação de dados de interface-usuário. Naturalmente, não há forma de apresentação oumodelo de programação universal; desse modo, as aplicações necessitam de mecanismosflexíveis para transformar entidades nas várias formas de apresentação.

A maioria das aplicações e serviços cêntricos em dados gostaria de raciocinar emtermos de conceitos de alto nível como um Pedido, não sobre as várias tabelas que um pe-dido pode ser normalizado sobre em um esquema de banco de dados relacionai. Um pedidopode se manifestar como o nível de apresentação/programação como uma ocorrência declasse em Visual Basic ou C# encapsulando o estado e lógica associada ao pedido, ou co-mo um fluxo XML para comunicar com um serviço de rede. Não há modelo de apresentaçãoadequado, entretanto há valor em fornecer um modelo conceptual concreto, e então ser ca-paz de utilizar esse modelo como a base para mapeamentos flexíveis para e a partir de vá-rios modelos de apresentação e outros serviços de dados de nível mais elevado.

Evolução de aplicações e serviços

As aplicações baseadas em dados 10-20 anos atrás eram tipicamente estruturadascomo monólitos de dados; sistemas fechados com lógica fatorados por funções de objeto-verbo (por exemplo, criar pedido, atualizar cliente) que interagiam com um sistema de bancode dados no nível de esquema lógico. Várias tendências significativas moldaram o modo emque aplicações baseadas em dados, modernas, são fatoradas e usadas hoje em dia. Asprincipais entre essas estão fatoração orientada para objeto, composição de aplicação denível de serviço, e serviços cêntricos em dados de nível mais elevado. Entidades conceptu-ais são uma parte importante das aplicações hoje em dia. Essas entidades devem ser ma-peadas para uma variedade de representações e ligadas a uma variedade de serviços. Nãohá uma ligação de serviço ou representação correta; XML, Representações de Objeto e Re-Iacional são todas importantes, porém não há uma única que seja suficiente para todas asaplicações. Há necessidade, portanto, de uma estrutura que suporte camada de modelagemde dados de nível mais elevado, e também permita que múltiplas camadas de apresentaçãosejam encaixadas - a Estrutura de entidade tem como objetivo atender essas exigências.

Serviços cêntricos em dados também estão evoluindo em um modo similar. Os ser-viços fornecidos por uma "plataforma de dados" há 20 anos eram mínimos e focalizavam emtorno do esquema lógico em um RDBMS. Esses serviços incluíam consulta e atualização,transações atômicas, e operações de volume como backup e carregar/extrair.O próprio Servidor SQL está evoluindo a partir de um RDBMS tradicional para umaplataforma de dados completa que provê diversos serviços cêntricos em dados de valor ele-vado em relação a entidades realizadas no nível de esquema conceptual. Vários serviçoscêntricos em dados de nível mais elevado no produto Servidor SQL - Replicação, Constru-tor de Relatório citando apenas alguns - estão fornecendo cada vez mais seus serviços nonível de esquema conceptual. Atualmente, cada um desses serviços tem uma ferramentaseparada para descrever entidades conceptuais e mapear as mesmas no nível de esquemalógico subjacente. O objetivo da Estrutura de Entidade é fornecer uma abstração conceptualde nível mais elevado, comum que todos esses serviços possam compartilhar.

A ESTRUTURA DE ENTIDADE

A estrutura ADO.NET da Microsoft que existia antes da Estrutura de Entidade des-crita aqui era uma tecnologia de acesso a dados que permitia que aplicações se conectas-sem a armazenagens de dados e manipulassem dados contidos nas mesmas de várias ma-neiras. Era parte da Estrutura Microsoft.NET e era altamente integrada com o resto da bi-blioteca de classe da Estrutura .NET. A estrutura ADO.NET anterior tinha duas partes prin-cipais: provedores e serviços. Provedores ADO.NET são os componentes que sabem comofalar com armazenagens específicas de dados. Provedores são compostos de três pedaçosde funcionalidade de núcleo: conexões gerenciam acesso à fonte de dados subjacente; co-mandos representam um comando (consulta, chamada de procedimento, etc.) a ser execu-tado contra a fonte de dados; e leitores de dados representam o resultado de execução decomando. Os serviços ADO.NET incluem componentes neutros de provedor como DataSetpara permitir cenários de programação de dados offline. (Um DataSet é uma representaçãode dados, residente em memória que provê um modelo de programação relacionai consis-tente independente da fonte de dados.)

Estrutura de entidade - visão geral

A Estrutura de Entidade ADO.NET forma o modelo de provedor ADO.NET existen-te, preexistente, e acrescenta a seguinte funcionalidade:

1. um novo modelo de dados conceptual, o Modelo de Dados de Entidade (EDM),para ajudar esquemas conceptuais de modelo.

2. uma nova linguagem de manipulação de dados (DML), SQL de Entidade, paramanipular ocorrências do EDM, e uma representação programática de uma consulta (árvo-res canônicas de comando) para comunicar com provedores diferentes.

3. a capacidade de definir mapeamentos entre o esquema conceptual e os esque-mas lógicos.

4. um modelo de programação de provedor ADO.NET contra o esquema conceptual.

5. Uma camada de serviços de objeto para fornecer funcionalidade como ORM.6. integração com tecnologia LINQ para tornar o mesmo fácil de programar contradados como objetos a partir de linguagens .NET.

O Modelo de dados de entidade

O Modelo de dados de entidade (EDM) permite desenvolvimento de aplicaçõescêntricas em dados ricos. Estende o modelo relacionai clássico com conceitos a partir dodomínio Ε-R. Na modalidade exemplar fornecida aqui, conceitos de organização no EDMincluem entidades e relações. Entidades representam itens de nível superior com identida-de, enquanto Relações são utilizadas para relacionar (ou descrever relações entre) duas oumais entidades.

Em uma modalidade, o EDM é baseado em valor como o modelo relacionai (eSQL), em vez que baseado em referência/objeto como C# (CLR). Vários modelos de pro-gramação de objeto podem ser facilmente dispostos no topo do EDM. Similarmente, o EDMpode mapear para uma ou mais implementações DBMS para persistência.

O EDM e SQL de entidade representam um modelo de dados mais ricos e Iingua-gem de manipulação de dados para uma plataforma de dados e são destinados a habilitaraplicações como CRM e ERP, serviços intensos em dados como Relatório, Inteligência co-mercial, Replicação e Sincronização, e aplicações intensas em dados para modelar e mani-pular dados em um nível de estrutura e semântica que é mais próximo a suas necessidades.

Os requerentes discutem agora vários conceitos pertinentes ao EDM.

Tipos de EDM

Um EntityType descreve a estrutura de uma entidade. Uma entidade pode ter zeroou mais propriedades (atributos, campos) que descrevem a estrutura da entidade. Adicio-nalmente, um tipo de entidade deve definir uma chave - um conjunto de propriedades cujosvalores identificam exclusivamente a ocorrência de entidade em uma coleção de entidades.

Um EntityType pode derivar de (ou subtipo) de outro tipo de entidade - o EDM suporta umúnico modelo de herança. As propriedades de uma entidade podem ser dos tipos simples oucomplexos. Um SimpIeTYpe representa tipos escalares (ou atômicos) (por exemplo, númerointeiro, série), enquanto um CompIexType representa propriedades estruturadas (por exem-plo, um Endereço). Um CompIexType é composto de zero ou mais propriedades, que po-dem ser elas próprias propriedades do tipo escalar ou complexo. Um ReIationshipType des-creve relações entre dois (ou mais) tipos de entidade. Esquemas EDM fornecem um meca-nismo de agrupamento para tipos - tipos devem ser definidos em um esquema. O espaçode nome do esquema combinado com o nome de tipo identifica exclusivamente o tipo espe-cífico.

Modelo de ocorrência EDM

Ocorrências de entidade (ou apenas entidades) estão logicamente contidas em umEntitySet. Um EntitySet é uma coleção homogênea de entidades, isto é, todas as entidadesem um EntitySet devem ser do mesmo EntityType (ou derivadas). Um EntitySet é conceitu-almente similar a uma tabela de banco de dados, enquanto uma entidade é similar a umalinha de uma tabela. Uma ocorrência de entidade deve pertencer exatamente a um conjuntode entidades. Em um modo similar, ocorrências de relação estão logicamente contidas em um ReIationshipSet. A definição de um ReIationshipSet abrange a relação. Isto é, identificaos EntitySets que contêm ocorrências dos tipos de entidade que participam na relação. UmReIationshipSet é similar de modo conceptual, a uma tabela de link em um banco de dados.SimpIeTypes e CompIexTypes podem ser também instanciados como propriedades de umEntitySet. Um EntityContainer é um agrupamento lógico de EntitySets e ReIationshipSets -similar a como um Esquema é um mecanismo de agrupamento para tipos EDM.

Um Esquema EDM de exemplo

Um esquema EDM de exemplo é mostrado abaixo:

<?xml version="l.O" encoding="utf-8"?><Schema Namespace=nAdventureWorks" Alias="Self" ...><EntityContainer Name="AdventureWorksContainer"><EntitySet Name=nESalesOrdersn

EntityType=uSelf.ESalesOrder" /><EntitySet Name="ESalesPersons"

EntityType=nSelf.ESalesPerson" /><AssociationSet Name="ESalesPersonOrders"

Association="Self.ESalesPersanOrder"><End Role=nESalesPerson"

EntitySet=nESalesPersòns" /><End Role=nEOrder" EntitySet=nESalesOrders" /></AssociationSet></EntityContainer>

<!— Sales Order Type Hierarchy—><EntityType Name="ESalesOrder" Key="Xd"><Property Name=nId" Type="Int32"

NulIable="false" /><Property Name=nAccountNum" Type="String"MaxLength=1115" /></EntityType>

<EntityType Name="EStoreSalesOrder"

BaseType=nSelf.ESalesOrder"><Property Name=nTax" Type=nDecimal"

Precision="2 8" Scale="4" /></EntityType>

<!— Person EntityType --><EntityType Name=nESalesPerson" Key="Id"><!— Properties from SSalesPersons table-—><Property Name=nId" Type="Int32"

Nullable="false" /><Property Name=11Bonus" Type=nDecimalnPreeision-"28" Seale=Mn /><!— Properties from SEmployees table—><Property Name=nTitle" Type=nString"

MaxLength="50" /><Property Name=nHireDaten Type="DateTime" /><!— Properties from the SContaets table—><Property Narae=nName" Type="String"

MaxLength="50" /><Property Name=nContact" Type=nSelf.ContaetInfo"Nullable="false" /></EntityType>CComplexType Name="ContactInfo">

<Property Name="Email" Type=lfString"

MaxLength="50" /><Property JSIame=llPhone" Type="String"MaxLength="25" /></ComplexType>

<Association Name="ESalesPersonOrder">

<End Role="EOrder" Type=nSelf.ESalesOrder"

Multiplicity="*" /><End Role="ESalesPersonn Multiplicity="l"Type=nSelf.ESalesPerson" /></Association></Schema>

Arquitetura de alto nível

Essa seção delineia a arquitetura da Estrutura de Entidade ADO.NET. Seus com-ponentes funcionais principais são ilustrados na figura 1 e compreendem o que se segue:

Provedores específicos de fonte de dados. A Estrutura de Entidade 100 forma omodelo de provedor de dados ADO.NET. Há provedores específicos 122-125 para váriasfontes de dados como Servidor SQL 151, 152, fontes relacionais 153, não relacionais 154 efontes de serviços de Rede 155. Os provedores 122-125 podem ser chamados de um APIde ProvedorADO.NET específico de armazenagem 121.

Provedor de EntityCIient. O provedor EntityCIient 110 representa uma camada deprogramação conceptual concreta. É um novo provedor de dados baseado em valor ondedados são acessados em termos de entidades e relações EDM e são consulta-dos/atualizados utilizando uma linguagem SQL baseada em entidade (SQL de entidade). Oprovedor EntityCIient 111 faz parte de um pacote de Serviços de dados de entidade 110 quetambém pode incluir serviços de metadados 112, uma canalização de consultar e atualizar113, suporte de transações 115, um runtime de gerenciador de visualização 116, e um sub-sistema de mapeamento de visualização 114 que suporta visualizações EDM atualizáveissobre tabelas relacionais planas. O mapeamento entre tabelas e entidades é especificadode forma declarativa através de uma linguagem de especificação de mapeamento.

Serviços de objeto e outras Camadas de programação. O componente Serviços deObjeto 131 da Estrutura de Entidade 100 provê uma abstração de objeto rico em relação aentidades, um conjunto rico de serviços em relação a esses objetos, e permite que aplica-ções programem uma experiência de codificação imperativa 161 utilizando construções delinguagem de programação familiares. Esse componente provê serviços de gerenciamentode estado para objetos (incluindo rastreamento de alteração, resolução de identidade), su-porta serviços para navegar e carregar objetos e relações, suporta consultas via LINQ eSQL de entidade utilizando componentes como Xlinq 132, e permite que objetos sejam atua-lizados e persistidos.

A Estrutura de Entidade permite que múltiplas camadas de programação similar a130 sejam encaixadas sobre a camada de serviços de dados de entidade baseada em valor110 exposta pelo provedor de EntityCIient 111.0 componente Serviços de Objeto 131 éuma tal camada de programação que alisa objetos CLR1 e provê funcionalidade semelhantea ORM.

O componente serviços de metadados 112 gerencia metadados para as necessida-des de tempo de desenho e runtime da Estrutura de Entidade 100, e aplicações sobre a Es-trutura de entidade. Todos os metadados associados a conceitos EDM (entidades, relações,EntitySets, ReIationshipSets), conceitos de armazenagem (tabelas, colunas, limitações) econceitos de mapeamento são expostos via interfaces de metadados. O componente demetadados 112 também serve como um link entre as ferramentas de modelagem de domí-nio que suporta desenho de aplicação acionado por modelo.

Ferramentas de metadados e desenho. A Estrutura de entidade 100 integra comdesigners de domínio 170 para permitir desenvolvimento de aplicação acionada por modelo.As ferramentas incluem ferramentas de projeto de EDM, ferramentas de modelagem 171,ferramentas de desenho de mapeamento 172, ferramentas de desenho de navegar 173,ferramentas de desenho de ligação 174, ferramentas de geração de código 175, e modela-dores de consulta.

Serviços. Serviços cêntricos em dados ricos como Relatório 141, Sincronização142, Serviços de rede 143 e Análise comercial podem ser construídos utilizando a Estruturade entidade 100.

PADRÕES DE PROGRAMAÇÃO

A Estrutura de entidade ADO.NET juntamente com LINQ aumenta a produtividadedo desenvolvedor de aplicação por reduzir significativamente o descasamento de impedân-cia entre dados e código de aplicação. Nessa seção os requerentes descrevem a evoluçãoem padrões de programação de acesso a dados nas camadas lógica, conceptual e de abs-tração de objeto.

Considere o seguinte fragmento de esquema relacionai baseado no banco de da-dos AdventureWorks de amostra. Esse banco de dados consiste em tabelas de Scontacts201, Semployees 202, SsaIesPersons 203, e SsaIesOrders 204, que podem seguir um es-quema relacionai como aquele ilustrado na figura 2.

SCorvtacts (Contactld, Name, Emailr Phone)SEmployees (EmployeeId, Title, HireDate)SSalesPersons (SalesPersonld, Bônus)SSalesOrders (SalesOrderId, SalesPersonld)

Considere um fragmento de código de aplicação para obter o nome e data de con-tratação de vendedores que foram contratados antes de alguma data (mostrado abaixo). Háquatro desvantagens principais nesse fragmento de código que têm pouco haver com aquestão comercial que necessita ser respondida. Primeiramente, embora a consulta possaser feita em inglês de forma muito sucinta, a instrução SQL é bem verbosa e requer que odesenvolvedor esteja ciente do esquema relacionai normalizado para formular a junção mul-ti-tabelas necessária para coletar as colunas apropriadas a partir de tabelas de SContacts,SEmployees, e SsaIesPerson. Adicionalmente, qualquer alteração nos esquemas de bancosde dados subjacentes necessitarão de alterações correspondentes no fragmento de códigoabaixo. Em segundo lugar, o usuário tem de definir uma conexão explícita com a fonte dedados. Em terceiro lugar, uma vez que os resultados retornados não são fortemente digita-dos, qualquer referência a nomes de colunas não existentes serão pegos somente apósexecução da consulta. Em quarto lugar, a instrução SQL é uma propriedade de série para oAPI de Comando e quaisquer erros em sua formulação serão somente pegos em tempo deexecução. Embora essa código seja gravado utilizando ADO.NET 2.0, o padrão de código esuas desvantagens se aplica a qualquer outro API de acesso a dados relacionais comoODBC, JDBC ou OLE-DB.

void EmpsByDate(DateTime date) {using( SqlConnection con =new SqlConnection (CONN_STRING) ) {con.Open();SqlCommand cmd = con. CreateCoiranand {) ;cmd. CommandText = (§"SELECT SalesPersonID, FirstName, HireDateFROM SSalesPersons spINNER JOIN SEmployees eON sp.SalesPersonID = e.EmployeeIDINNER JOIN SContacts CON e.EmployeeID » c.ContactIDWHERE e.HireDate < Sdate";cmd.Parameters.AddWithValue("Sdate",date);

DbDataReader r = cmd.ExecuteReader();while(r.Read()) {Console.WriteLine("{O:d}:\t{l}",r["HireDaten], r["FirstNáme"]);} ) )

O esquema relacionai de amostra pode ser capturado no nível conceptual via umesquema EDM, como ilustrado na figura 3. Define um tipo de entidade ESaIesPerson 302que abstrai a fragmentação de tabelas de SContacts201, SEmployees 202 e SSalesPersons203. Captura também a relação de herança entre os tipos de entidade EStoreOrder 301 eESaIesOrder 303.

O programa equivalente na camada conceptual é gravado como a seguir:void EmpsByDate (DateTime date) {using{ EntityConnection con =

new EntityConnection (CONN_STRING) ) {con.Open();

EntityCommand cmd = con.CreateCommand () ;cmd.CommandText =SELECT VALUE spFROM ESalesPersons spWHERE sp.HireDate < Sdate";cmd. Parameters .AddWithValue ( "date",date);

DbDataReader r = cmd.ExecuteReader(

CqmmandBehavior.SequentialAccess);while (r.ReadO) {

Console . WriteLine ("{O : d}:\t {1}".,r["HireDate"]], r["FirstName"])

} ) )

A instrução SQL foi consideravelmente simplificada - o usuário não mais precisasaber sobre a disposição precisa do banco de dados. Além disso, a lógica de aplicação po-de ser isolada a partir de alterações no esquema de banco de dados subjacente. Entretanto,esse fragmento ainda é baseado em série, ainda não obtém os benefícios da checagem dotipo de linguagem de programação e retorna resultados digitados de forma fraca.

Pela adição de um wrapper around de objeto fino, de entidades e utiliza as exten-sões de Consulta Integrada de Linguagem (LINQ) em C#, pode-se regravar a função equiva-lente sem descasamento de impedância como a seguir:

void EmpsByDate(DateTime date) {using (AdventureWorksDB aw =new AdventureWorksDBC)) {var people = from ρ in aw.SalesPersonswhere p.HireDate < dateselect p;

foreach (SalesPerson ρ in people) {Console.WriteLine("{O:d}\t{1}",p.HireDate, p.FirstName);

} > >

A consulta é simples; a aplicação é (grandemente) isolada de alterações no es-quema de banco de dados subjacente; e a consulta é totalmente checada em tipo pelo com-pilador C#. Além das consultas, pode-se interagir com objetos e executar operações regula-res Criar, Ler, Atualizar e Deletar (CRUD) nos objetos. Os exemplos desses são descritosna seção Processamento de atualização.

SERVIÇOS DE OBJETO

O componente Serviços de Objeto é uma camada de apresentação/programaçãosobre a camada conceptual (entidade). Aloja vários componentes que facilitam a interaçãoentre a linguagem de programação e as entidades de camada conceptual baseada em valor.Os requerentes esperam que um serviço de objeto exista por runtime de linguagem de pro-gramação (por exemplo, .NET1 Java). Se for projetado para suportar o .NET CLR1 os pro-gramas em qualquer linguagem .NET podem interagir com a Estrutura de Entidade. Serviçosde Objeto são compostos dos seguintes componentes principais:

A classe ObjectContext aloja a conexão de banco de dados, espaço de trabalho demetadados, gerenciador de estado de objeto, e materializador de objeto. Essa classe incluiuma interface de consulta de objeto ObjectQuery<T> para habilitar a formulação de consul-tas em SQL de entidade ou sintaxe LINQ1 e retoma resultados de objeto digitados fortemen-te como um ObjectReader<T>. O ObjectContext também expõe interface de nível-objeto deconsulta e atualização (isto é, SaveChanges) entre a camada de linguagem de programaçãoe a camada conceptual. O gerenciador de estado de objeto tem três funções principais: (a)cache de resultados de consulta, fornecendo resolução de identidade, e programas de ge-renciamento para fundir objetos a partir de resultados de consulta sobrepostos, (b) rastrearalterações em memória, e (c) construir a entrada de lista de alteração para a infra-estruturade processamento de atualização. O gerenciador de estado de objeto mantém o estado decada entidade no cache - desprendido (a partir do cache), adicionado, inalterado, modifica-do e deletado - e rastreia suas transições de estado. O materializador de objeto executa astransformações durante consulta e atualização entre valores de entidade a partir da camadaconceptual e os objetos CLR correspondentes.

MAPEAMENTO

Em uma modalidade, a armação de uma camada de acesso a dados de propósitogeral como a Estrutura de Entidade ADO.NET pode ser um mapeamento que estabeleceuma relação entre os dados de aplicação e os dados armazenados no banco de dados.

Uma aplicação consulta e atualiza dados no objeto ou nível conceptual e essas operaçõessão traduzidas para a armazenagem através do mapeamento. Há um número de desafiostécnicos que têm de ser tratados por qualquer solução de mapeamento. É relativamentedireto construir um ORM que utilize um mapeamento de um a um para expor cada linha emuma tabela relacionai como um objeto, especialmente se nenhuma manipulação de dadosdeclarativos for necessária. Entretanto, como mapeamentos mais complexos, operaçõesbaseadas em conjunto, desempenho, suporte de vendedor-multi-DBMS, e outras exigênciaspesam, soluções ad hoc crescem rapidamente de improviso.

Problema: atualizações via mapeamento

O problema de acessar dados via mapeamentos pode ser modelado em termos de"visualizações", isto é, os objetos/entidades na camada de cliente podem ser consideradoscomo visualizações ricas em relação às linhas de tabela. Entretanto, é bem sabido que so-mente uma classe limitada de visualizações é atualizável, por exemplo, sistemas de bancode dados comerciais não permitem atualizações para múltiplas tabelas em visualizaçõescontendo junções ou uniões. Encontrar uma tradução de atualização única sobre visualiza-ções até mesmo bem simples é raramente possível devido a subespecificação intrínseca docomportamento de atualização por uma visualização. A pesquisa mostrou que instigar a se-mântica de atualização a partir das vistas é difícil e pode exigir experiência significativa do usuário. Entretanto, para acesso de dados acionado por mapeamento, é vantajoso que hajauma tradução bem definida de toda atualização para a visualização.

Além disso, em cenários acionados por mapeamento, a exigência de capacidade deatualização vai além de uma única visualização. Por exemplo, uma aplicação comercial quemanipula entidades Cliente e Pedido desempenha eficazmente operações contra duas visu-alizações. Às vezes um estado de aplicação consistente pode ser obtida somente por atuali-zação de várias visualizações simultaneamente. A tradução caso a caso de tais atualizaçõespode fornecer uma explosão combinatória da lógica de atualização. Delegar sua implemen-tação a desenvolvedores de aplicação é insatisfatório porque requer que os mesmos lidemmanualmente com uma das partes mais complicadas de acesso a dados.

A abordagem de mapeamento ADO.NET

A Estrutura de entidade ADO.NET suporta uma arquitetura de mapeamento inova-dora que tem como objetivo tratar dos desafios acima. Explora as seguintes idéias:

1. especificação: mapeamentos são especificados utilizando uma linguagem decla-rativa que tem semântica bem definida e coloca uma ampla gama de cenários de mapea-mento no alcance de usuários não experientes.

2. compilação: mapeamentos são compilados em visualizações bidirecionais, de-nominadas visualizações de consulta e atualização que acionam o processamento de con-sulta e atualização no motor de runtime.

3. Execução: a tradução de atualização é feita utilizando um mecanismo geral quealavanca manutenção materializada de visualização, uma tecnologia de banco de dadosrobusta. A tradução de consulta utiliza revelação de visualização.

A nova arquitetura de mapeamento permite a construção de uma pilha poderosa detecnologias acionadas por mapeamento em um modo de princípio à prova de futuro. Alémdisso, abre direções de pesquisa interessantes de relevância prática imediata. As subseçõesa seguir ilustram a especificação e compilação de mapeamentos. A execução é consideradanas seções de Processamento de consulta e Processamento de atualização, abaixo. Alémdisso aspectos e modalidades de uma arquitetura de mapeamento exemplar como forneci-dos aqui são também expostos na seção abaixo intitulada "Aspectos e modalidades adicio-nais".

Especificação de mapeamentos

Um mapeamento é especificado utilizando um conjunto de fragmentos de mapea-mento. Cada fragmento de mapeamento é uma limitação da forma QEntities = QTabies onde QEn-Oties é uma consulta em relação ao esquema de entidade (no lado de aplicação) e Qiabies éuma consulta em relação ao esquema de banco de dados (no lado de armazenagem). Umfragmento de mapeamento descreve como uma porção de dados de entidade corresponde auma porção de dados relacionais. Isto é, um fragmento de mapeamento é uma unidade e-lementar de especificação que pode ser entendida independentemente de outros fragmentos.

Para ilustrar, considere o cenário de mapeamento de amostra na figura 4. A figura 4ilustra um mapeamento entre um esquema de entidade (esquerda) e um esquema de bancode dados (direita). O mapeamento pode ser definido utilizando um arquivo XML ou uma fer-ramenta gráfica. O esquema de entidade corresponde a um na seção de Modelo de dadosde entidade aqui. NO lado de armazenagem há quatro tabelas, SSaIesOrders1 SSaIesPer-sons, SEmpIoyees e SContacts. No lado de esquema de entidade há dois conjuntos de enti-dade, ESaIesOrder e ESalesPersons, e um conjunto de associação, EsalesPersonOrders.

O mapeamento é representado em termos de consultas no esquema de entidade eesquema relacionai como mostrado na figura 5.

Na figura 5, o fragmento 1 diz que o conjunto de (ld, AccountNUm) valores para to-das as entidades de ESaIesOrder de tipo exato em EsaIesOrders é idêntico ao conjunto devalores de (SalesOrderld, AcountNum) recuperados a partir da tabela SsaIesOrders para aqual IsOnline é verdadeiro. O fragmento 2 é similar. O fragmento 3 mapeia o conjunto deassociações EsalesPersonOrders para a tabela SsaIesOrders e diz que cada entrada deassociação corresponde ao par de chave primária, chave estranha para cada linha nessatabela. Os fragmentos 4, 5 e 6 dizem que as entidades no conjunto de entidades EsaIesPer-sons são divididas através de três tabelas SsaIesPerrsons, SContacts, SEmployees.

Visualizações bidirecionais

Os mapeamentos são compilados em visualizações SQL de Entidade bidirecionaisque acionam o runtime. As visualizações de consulta expressam entidades em termos detabelas, enquanto as visualizações de atualização expressam tabelas em termos de entida-des.

Visualizações de atualização podem ser de um certo modo contra-intuitivas porqueespecificam dados persistentes em termos de construções virtuais, porém como os reque-rentes mostram posteriormente, podem ser alavancadas para suportar atualizações em ummodo elegante. As visualizações geradas 'respeitam' o mapeamento em um sentido bemdefinido e têm as seguintes propriedades (observe que a apresentação é levemente simplifi-cada - em particular, o estado persistente não é totalmente determinado pelo estado virtual):

Entidades = Visualizações de consulta (Tabelas)

Tabelas = Visualizações de atualização (Entidades)

Entidades = Visualizações de consulta (Visualizações de atualização (Entidades)A última condição é o critério de viagem de ida e volta, que assegura que todos osdados de entidade podem ser persistidos e remontados a partir do banco de dados em ummodo sem perda. O compilador de mapeamento incluído na Estrutura de Entidade asseguraque as visualizações geradas atendem o critério de viagem de ida e volta. Origina um errose nenhuma tal visualização puder ser produzida a partir do mapeamento de entrada.

A figura 6 mostra as visualizações bidirecionais - as visualizações de consulta e a-tualização - geradas pelo compilador de mapeamento para o mapeamento na figura 5. Emgeral, as visualizações podem ser significativamente mais complexas do que o mapeamentode entrada, visto que explicitamente especificam as transformações necessárias de dados.

Por exemplo, em QV1 o conjunto de entidade EsaIesOrders é construído a partir da tabelaSsaIesOrders de modo que um ESaIesOrder ou um EstoreSaIesOrder é instanciado depen-dendo de se ou não o indicador IsOnIine é verdadeiro. Para remontar o conjunto de entidadeEsaIesPersons a partir das tabelas relacionais, é necessário executar uma junção entre astabelas SSalesPersons, SEmpIoyees e SContacts (QV3).

Escrever visualizações de consulta e atualização a mão que atendam ao critério deviagem de ida e volta é complicado e requer experiência significativa em banco de dados;portanto, as presentes modalidades da Estrutura de Entidade aceitam somente as visualiza-ções produzidas pelo compilador de mapeamento incorporado, embora aceitar visualizaçõesproduzidas por outros compiladores ou a mão é certamente plausível em modalidades alter-nativas.

Compilador de mapeamento

A Estrutura de Entidade contém um compilador de mapeamento que gera as visua-lizações de consulta e atualização a partir do esquema EDM, esquema de armazenagem, emapeamento (os artefatos de metadados são discutidos na seção Metadados aqui). Essasvisualizações são consumidas pelas canalizações de consulta e atualização. O compiladorpode ser invocado no momento de desenho ou em runtime quando a primeira consulta éexecutada contra o esquema EDMA. Os algoritmos de geração de visualização utilizados nocompilador se baseiam nas técnicas de responder a consultas utilizando visualizações pararegravações exatas.

PROCESSAMENTO DE CONSULTA

Linguagens de consulta

Em uma modalidade, a Estrutura de Entidade pode ser projetada para trabalharcom múltiplas linguagens de consulta. Os requerentes descrevem modalidades de LINQ eSQL de Entidade em mais detalhes aqui, entendendo que os princípios iguais ou similarespodem ser estendidos a outras modalidades.

SQL de Entidade

SQL de entidade é derivativo de SQL projetado para consultar e manipular ocorrên-cias de EDM. SQL de entidade estende SQL padrão nos seguintes modos.

1. Suporte nativo para construções EDM (entidades, relações, tipos complexos,etc.): construtores, meios de acesso a membro, tipo de interrogação, relação de navegação,aninhar/desaninhar, etc.

2. Espaços de nome. SQL de entidade utiliza espaços de nome como uma constru-ção de agrupamento para tipos e funções (similares a Xquery e outras linguagens de pro-gramação).

3. Funções extensíveis. SQL de entidade não suporta funções incorporadas. Todasas funções (min, max, subsérie, etc.) são definidas externamente em um espaço de nome, eimportadas para uma consulta, normalmente a partir da armazenagem subjacente.

4. Tratamento mais ortogonal de subconsultas e outras construções em compara-ção com SQL.

A Estrutura de entidade pode, por exemplo, suportar SQL de entidade como a lin-guagem de consulta na camada de provedor EntityCIient, e no componente de Serviços deObjeto. Uma consulta de SQL de entidade de amostra é mostrada na seção Padrões de

Programação aqui.

Consulta integrada de linguagem (LINQ)

Consulta integrada de linguagem, ou LINQ, é uma inovação em linguagens de pro-gramação .NET que introduz construções relacionadas à consulta para linguagens de pro-gramação de corrente principal como C# e Visual Basic. As expressões de consulta não sãoprocessadas por uma ferramenta externa ou pré-processador de linguagem porém em vezdisso são expressões de primeira classe das próprias linguagens. LINQ permite que expres-sões de consulta se beneficiem dos metadados ricos, checagem de sintaxe de tempo decompilar, digitação estática e InteIIiSence que era previamente disponível somente para có-digo imperativo. LINQ define um conjunto de operadores de consulta padrão de propósitogeral que permitem que operações de percurso, filtro, junção, projeção, separação e agru-pamento sejam expressas em um modo direto ainda assim declarativo em qualquer lingua-gem de programação baseada em .NET. Linguagens .NET como Visual Basic e C# tambémsuportam compreensões de consulta - extensões de sintaxe de linguagem que alavancamos operadores de consulta padrão. Uma consulta de exemplo que utiliza LINQ e C# é mos-trada na seção Padrões de Programação da presente invenção.

Árvores canônicas de comando

Em uma modalidade, Árvores canônicas de comando - mais simplesmente, árvoresde comando - podem ser a representação programática (árvore) de todas as consultas emuma Estrutura de Entidade. Consultas expressas via SQL de entidade ou LINQ podem serprimeiramente analisadas e convertidas em árvores de comando; todo processamento sub-seqüente pode ser executado nas árvores de comando. A Estrutura de Entidade tambémpode permitir que consultas sejam dinamicamente construídas (ou editadas) via APIs deedição/construção de árvore de comando. Árvores de comando podem representar consul-tas, inserções, atualizações, deleções e chamadas de procedimento. Uma árvore de co-mando é composta de uma ou mais Expressões. Uma Expressão representa simplesmenteum pouco de computação - a Estrutura de entidade pode fornecer uma variedade de ex-pressões incluindo constantes, parâmetros, operações aritméticas, operações relacionais(projeção, filtro, junção, etc.) chamadas de função e assim por diante. Finalmente, árvoresde comando podem ser utilizadas como o meio de comunicação para consultas entre o pro-vedor de EntityCIient e o provedor específico de armazenagem subjacente.

Canalização de consulta

A execução de consulta em uma modalidade de uma Estrutura de Entidade podeser delegada às armazenagens de dados. A infra-estrutura de processamento de consultada Estrutura de Entidade é responsável por dividir uma consulta de SQL de Entidade ouLINQ em uma ou mais consultas elementares, relacionais somente que podem ser avaliadaspela armazenagem subjacente, juntamente com informações de montagem adicionais, quesão utilizadas para remodelar os resultados planos das consultas mais simples em estrutu-ras EDM mais ricas.

A Estrutura de Entidade pode assumir, por exemplo, que armazenagens devem su-portar capacidades similares àquelas de Servidor SQL 2000. Consultas podem ser divididasem consultas relacionais-planas mais simples que se encaixam nesse perfil. Outras modali-dades de uma Estrutura de Entidade poderiam permitir que armazenagens assumissem par-tes maiores de processamento de consulta.

Uma consulta típica pode ser processada como a seguir.

Análise semântica e de sintaxe. Uma consulta de SQL de Entidade é primeiramenteparsed e analisada semanticamente utilizando informações a partir do componente de servi-ços de Metadados. Consultas de LINQ são parsed e analisadas como parte do compiladorde linguagem apropriado.

Conversão em uma árvore canônica de comando. A consulta é agora convertida emuma árvore de comando, independente de como foi originalmente expressa, e validada.

Revelação de visualização de mapeamento. Consultas na Estrutura de Entidadesão dirigidas a esquemas (EDM) conceptuais. Essas consultas devem ser traduzidas parareferenciar as tabelas de banco de dados subjacentes e visualizações em vez disso. Esseprocesso - mencionado como revelação de visualização de mapeamento - é análogo aomecanismo de revelação de visualização em sistemas de banco de dados. Os mapeamen-tos entre o esquema EDM e o esquema de banco de dados são compilados em visualiza-ções de consulta e atualização. A visualização de consulta é então revelada na consulta deusuário - a consulta agora é dirigida às visualizações e tabelas de banco de dados.Eliminação de tipo estruturado. Todas as referências a tipos estruturados são agoraeliminados a partir da consulta, e adicionados às informações de montagem (para guiar amontagem de resultado). Isso inclui referências a tipo de construtores, meios de acesso amembro, expressões do tipo de interrogação.

Poda de projeção: a consulta é analisada, e expressões não referenciadas na con-sulta são eliminadas.

Pull-up de aninhar. Quaisquer operações de aninhamento (construir coleções ani-nhadas) na consulta são empurradas para cima para a raiz da árvore de consulta sobre umasub-árvore contendo somente operadores relacionais planos. Tipicamente, a operação deaninhamento é transformada em uma junção externa esquerda (ou uma aplicação externa),e os resultados planos a partir da consulta seguinte são então remontados (vide Montagemde resultados abaixo) nos resultados apropriados.

Transformações. Um conjunto de transformações heurísticas é aplicado para simpli-ficar a consulta. Essas incluem empurrar filtro para baixo, conversões de aplicação para jun-ção, envolver expressão de caso, etc. Junções redundantes (auto-junções, junções de cha-ve estranha, chave primária) são eliminadas nesse estágio. Observe que a infra-estrutura deprocessamento de consulta não executa aqui nenhuma otimização baseada em custo.

Tradução em comandos específicos de provedor. A consulta (isto é, árvore de co-mando) é agora entregue a provedores para produzir um comando específico de provedor,possivelmente no dialeto SQL nativo dos provedores. Os requerentes se referem a essaetapa como SQLGen.

Execução. Os comandos de provedor são executados.

Montagem de resultado. Os resultados (DataReaders) a partir dos provedores sãoentão remodelados na forma apropriada utilizando as informações de montagem reunidasanteriormente, e um único DataReader é retornado ao chamador.

Materialização. Para consultas emitidas através do componente Serviços Objeto, osresultados são então materializados nos objetos de linguagem de programação apropriados.

SQLGen

Como mencionado na seção anterior, execução de consulta pode ser delegada àarmazenagem subjacente. Em tais modalidades, uma consulta deve ser primeiramente tra-duzida em uma forma que é apropriada para a armazenagem. Entretanto, armazenagensdiferentes suportam dialetos diferentes de SQL, e é impraticável para uma Estrutura de En-tidade suportar de forma nativa, todos eles. Em vez disso, a canalização de armazenagempode traduzir então a árvore de comando em um comando nativo. Isso pode ser realizadotraduzindo a árvore de comando no dialeto SQL nativo do provedor - conseqüentemente otermo SQLGen para essa fase. O comando resultante pode ser então executado para pro-duzir os resultados relevantes.PROCESSAMENTO DE ATUALIZAÇÃO

Essa seção descreve como o processamento de atualização pode ser executado naEstrutura de Entidade ADO.NET exemplar. Em uma modalidade, há duas fases para o pro-cessamento de atualização, tempo de compilar e runtime. Na seção Visualizações Bidirecio-nais fornecida aqui, os requerentes descreveram o processo de compilar a especificação demapeamento em uma coleção de expressões de visualização. Essa seção descreve comoessas expressões de visualização são exploradas em runtime para traduzir as modificaçõesde objeto executadas na camada de objeto (ou atualizações DML de SQL de entidade nacamada EDM) em atualizações SQL equivalentes na camada relacionai.

Atualizações via Manutenção de visualização

Um dos insights explorados na arquitetura de mapeamento ADO.NET exemplar éque algoritmos de manutenção de visualização materializados podem ser alavancados parapropagar atualizações através de visualizações bidirecionais. Esse processo é ilustrado nafigura 7.

As tabelas dentro de um banco de dados, como ilustrado no lado direito da figura 7,contêm dados persistentes. Um EntityContainer, como ilustrado no lado esquerdo da figura7, representa um estado virtual desses dados persistentes uma vez que tipicamente somen-te uma minúscula fração das entidades nos EntitySets e materializada no cliente. O objetivoé traduzir um AEntities de atualização no estado de Entidades em um ATabeIs de atualiza-ção no estado persistente de Tabelas. Esse processo é mencionado como manutenção devisualização incrementai, porque a atualização é executada com base no AEntities de atuali-zação representando os aspectos alterados de uma entidade.

Isso pode ser feito utilizando as duas etapas a seguir:

1. Manutenção de visualização:^ TabIes = AUpdateViews (Entidades, AEntities)

2. Revelação de visualização:^ TabIes = AUpdateViews (QueryViews(Tables), AEntities)

Na etapa 1, algoritmos de manutenção de visualização são aplicados para atualizarvisualizações. Isso produz um conjunto de expressões delta, AUpdadeViews, que nos infor-mará sobre como obter ATabIes a partir de AEntities e um snapshot de Entidades. Uma vezque o último não é totalmente materializado no cliente, na Etapa 2 revelação de visualizaçãoé utilizada para combinar as expressões delta com visualizações de consulta. Juntas, essasetapas geram uma expressão que toma como entrada o estado de banco de dados inicial ea atualização para entidades, e computa a atualização para o banco de dados.

Essa abordagem fornece um algoritmo uniforme, claro que trabalha tanto para atua-lizações baseadas em conjunto e objeto-de-cada-vez (isto é, aquelas expressas utilizandoinstruções de manipulação de dados), e alavanca tecnologia robusta de banco de dados. Naprática, a Etapa 1 é freqüentemente suficiente para tradução de atualização uma vez quemuitas atualizações não dependem diretamente do estado de banco de dados atual; nessassituações temos ATabIes = AUpdateViews(AEntities). Se AEntities for dado como um conjun-to de modificações objeto-de-cada-vez em entidades em cache, então a Etapa 1 pode seradicionalmente otimizada pela execução de algoritmos de manutenção de visualização dire-tamente nas entidades modificadas em vez de computar a expressão AUpdateViews.

Tradução de atualizações em objetos

Para ilustrar a abordagem delineada acima, considere o exemplo a seguir que for-nece um bônus e promoção para vendedores com direito que estão com a companhia hápelo menos 5 anos.

using(AdventureWorksDB aw β

new AdventureWorksDB (...) ) {// People hired at least 5 years agoDatetime d = DateTime.Today.AddYears(-5);var people = from ρ in aw.SalesPeoplewhere p.HireDate < dseIect p;

foreach(SalesPerson ρ in people) {

if(HRWebService.ReadyForPromotion(p)) {p.Bonus += 10;

p.Title = "Sênior Sales Representative";

}

}

aw.SaveChanges(); // push changes to DB

}

AdventureWorksDB é uma classe gerada por ferramenta que deriva de uma classede serviços de objeto genérica, denominada ObjectContext, que aloja a conexão de bancode dados, espaço de trabalho de metadados, e estrutura de dados de cache de objeto eexpõe o método SaveChanges. Como os requerentes explicaram na seção Serviços de Ob-jeto, o cache de objeto mantém uma lista de entidades, cada uma das quais está em um dosseguintes estados: desprendida (a partir do cache), adicionada, inalterada, modificada edeletada. O fragmento de código acima descreve uma atualização que modifica as proprie-dades de título e bônus de objetos EsaIesPerson que são armazenados nas tabelas SEm-ployees e SSalesPersons, respectivamente. O processo de transformar as atualizações deobjeto nas atualizações de tabela correspondentes desencadeadas pela chamada para ométodo SaveChanges pode compreender as quatro etapas a seguir:

Geração de lista de alteração. Uma lista de alterações por conjunto de entidades écriada a partir do cache de objeto. Atualizações são representadas como listas de elementosdeletados e inseridos. Objetos adicionados se tornam inserções. Objetos deletados se tor-nam deleções.

Propagação de expressão de valor. Essa etapa toma a lista de alterações e as vi-sualizações de atualização (mantidas no espaço de trabalho de metadados), e utilizandoexpressões de manutenção de visualização materializada AUpdateViews, transforma a listade alterações de objeto em uma seqüência de expressões de inserção e deleção de tabelade base algébrica contra as tabelas afetadas subjacentes. Para esse exemplo, as visualiza-ções de atualização relevantes são υνΔ2Δ e UVA3A mostradas na figura 6. Essas visualiza-ções são consultas de selecionar projeto simples, desse modo a aplicação de regras de ma-nutenção de visualização é direta. Os requerentes obtiveram as seguintes expressões AUp-dateViews, que são iguais para inserções (Δ+) e deleções (Δ"):

ASSalesPersons = SELECT p.Id, p.Bonus

FROM AESalesPersons AS ρ

ASEmployees = SELECT p.Id, p.Title

FROM AESalesPersons AS ρ

ASContacts = SELECT p.Id, p.Name, p.Contact.Email,

p.Contact.Phone FROM AESalesPersons AS ρ

Suponha que o Ioop mostrado acima atualizou a entidade E0|d = EsaIesPersons (1,20, "", "Alice, Contactfa@sales. NULL)) para Enew= EsalersPersons(1, 30, "Sênior...", "Alice,Contact(a@sales. NULL)). Então, o delta inicial é A+EsaIesOrders = {Enew} para inserções eA EsaIesOrders = {E0|d} para deleções. Os requerentes obtêm A+SSalesPersons = {(1,30)}, A"SSalesPersons = {(1,20)}. As inserções e deleções computadas na tabela SsaIesPerrsonssão então combinadas em uma única atualização que define o valor de Bônus em 30. Osdetalhes em SEmpIoyees são computados de forma análoga. Para SContacts, os requeren-tes obtém A+SContacts = A"SContacts, assim nenhuma atualização é necessária.

Além de computar os deltas nas tabelas de base afetadas, essa fase é responsávelpor (a)ordenação correta na qual as atualizações de tabela devem ser executadas, levandoem consideração limitações de integridade referencial, (b) recuperação de chaves geradasem armazenagem necessárias antes de submeter as atualizações finais ao banco de dados,e (c) reunir as informações para controle de conformidade otimista.

Geração de chamadas de procedimento armazenadas ou SQL DML. Essa etapatransforma a lista de deltas inseridos e deletados mais anotações adicionais relacionadas àmanipulação de conformidade em uma seqüência de instruções SQL DML ou chamadas deprocedimento armazenadas. Nesse exemplo, as instruções de atualização geradas para ovendedor afetado são:

UPDATE [dbo].[SSalesPersons] SET [Bonus]=30

WHERE [SalesPersonlD]=1

UPDATE [dbo].[SEmployees]

SET [Title]= N1Senior Sales Representative'

WHERE [EmployeelD]=1

END TRANSACTION

Sincronização de cache. Após execução das atualizações, o estado do cache é sin-cronizado com o novo estado do banco de dados. Desse modo, se necessário, uma etapade processamento de consulta mini é realizada para transformar o novo estado relacionaimodificado em sua entidade correspondente e estado de objeto.

METADADOS

O subsistema de metadados é análogo a um catálogo de banco de dados, e é pro-jetado para satisfazer as necessidades de metadados de runtime e tempo de desenho daEstrutura de entidade.

Artefatos de metadados

Artefatos de metadados podem incluir, por exemplo, o que se segue:

Esquema conceptual (arquivos CSDL); o esquema conceptual pode ser definido emum arquivo CSDL (Linguagem de definição de esquema conceptual) e contém os tipos EDM(tipos de entidade, relações) e conjuntos de entidade que descrevem a visualização concep-tual da aplicação dos dados.

Esquema de armazenagem (arquivos SSDL): a informação de esquema de arma-zenagem (tabelas, colunas, chaves, etc.) pode ser expressa utilizando termos de vocabulá-rio CSDL. Por exemplo, EntitySets denotam tabelas, e propriedades denotam colunas. Es-sas podem ser definidas em um arquivo SSDL (Linguagem de Definição de esquema dearmazenagem).

Especificação de mapeamento C-S (arquivo MSL): o mapeamento entre o esquemaconceptual e o esquema de armazenagem é capturado em uma especificação de mapea-mento, tipicamente em um arquivo MSL (Linguagem de especificação de mapeamento).Essa especificação é utilizada pelo compilador de mapeamento para produzir as visualiza-ções de consulta e atualização.

Manifesto de provedor: Um Manifesto de provedor pode fornecer uma descrição defuncionalidade suportada por cada provedor, e pode incluir as seguintes informações exem-plares:

1. os tipos primitivos (varchar, int, etc.) suportados pelo provedor, e os tipos EDM(série, int32, etc.) com os quais eles correspondem.

2. as funções incorporadas (e suas assinaturas) para o provedor.

Essas informações podem ser utilizadas pelo parser de SQL de entidade como par-te de análise de consulta. Além desses artefatos, o subsistema de metadados também poderastrear as classes de objeto geradas, e os mapeamentos entre essas e os tipos de entida-de conceptual correspondentes.

Arquitetura de serviços de metadados

Os metadados consumidos pela Estrutura de Entidade podem vir de fontes diferen-tes em diferentes formatos. O subsistema de metadados pode ser construído sobre um con-junto de interfaces de metadados de nível baixo unificadas que permitem que o runtime tra-balhe independentemente dos detalhes das diferentes fontes/formatos persistentes de me-tadados.

Serviços de metadados exemplares podem incluir:

Enumeração de tipos diferentes de metadados.

Busca de metadados por chave.

Navegação/browsing de metadados.

Criação de metadados transientes (por exemplo, para processamento de consulta).

Caching e reutilização de metadados independentes de sessão.

O subsistema de metadados inclui os seguintes componentes. O cache de metada-dos caches metadados recuperados a partir de fontes diferentes, e provê aos consumidoresum API comum para recuperar e manipular os metadados. Uma vez que os metadados po-dem ser representados em formas diferentes, e armazenados em locais diferentes, o subsis-tema de metadados podem suportar vantajosamente uma interface de carregador. Carrega-dores de metadados implementam a interface de carregador, e são responsáveis por carre-gamento dos metadados a partir da fonte apropriada (arquivos CSDL/SSDL, etc.). Um espa-ço de trabalho de metadados agrega vários pedaços de metadados para fornecer o conjuntocompleto de metadados para uma aplicação. Um espaço de trabalho de metadados contémnormalmente informações sobre o modelo conceptual, o esquema de armazenagem, asclasses de objeto e os mapeamentos entre essas construções.

FERRAMENTAS

Em uma modalidade, uma Estrutura de entidade pode incluir também uma coleçãode ferramentas de tempo de desenho para aumentar a produtividade de desenvolvimento.Ferramentas exemplares são:

Designer de modelo: uma das etapas iniciais no desenvolvimento de uma aplicaçãoé a definição de um modelo conceptual. A Estrutura de entidade permite que designers deaplicação e analistas descrevam os principais conceitos de sua aplicação em termos de en-tidades e relações. O designer de modelo é uma ferramenta que permite que essa tarefa demodelagem conceptual seja executada de forma interativa. Os artefatos do desenho sãocapturados diretamente no componente de Metadados que podem persistir seu estado nobanco de dados. O designer de modelo também pode gerar e consumir descrições de mo-delo (especificado via CSDL), e podem sintetizar modelos EDM a partir de metadados rela-cionais.

Designer de mapeamento: Após um modelo EDM ter sido projetado, o desenvolve-dor pode especificar como um modelo conceptual mapeia para um banco de dados relacio-nai. Essa tarefa é facilitada pelo designer de mapeamento, que pode apresentar uma inter-face de usuário, como ilustrado na figura 8. O designer de mapeamento ajuda os desenvol-vedores a descrever como as entidades e relações em um esquema de entidade apresenta-do no lado esquerdo de interface de usuário mapeiam para tabelas e colunas no banco dedados, como refletido em um esquema de banco de dados apresentado no lado direito dainterface de usuário na figura 8. Os links no gráfico apresentado na seção média da figura 8visualizam as expressões de mapeamento especificadas de forma declarativa como igual-dades de consultas SQL de entidade. Essas expressões se tornam a entrada para o com-ponente de compilação de mapeamento bidirecional que gera as visualizações de consulta eatualização.

Geração de código: o modelo conceptual EDM é suficiente para muitas aplicaçõesvisto que provê um modelo de interação familiar com base em padrões de código ADO.NET(comandos, conexões, leitores de dados). Entretanto, muitas aplicações preferem interagircom dados como objetos fortemente digitados. A Estrutura de Entidade inclui um conjuntode ferramentas de geração de código que tomam modelos EDM como entrada e produzemclasses CLR fortemente digitadas para tipos de entidade. As ferramentas de geração decódigo também podem gerar um contexto de objeto fortemente digitado (por exemplo, Ad-ventureWorksDB) que expõe coleções fortemente digitadas para todos os conjuntos de rela-ção e entidade definidos pelo modelo (por exemplo, ObjectQuery<SalesPerson>).

Modalidades e aspectos adicionais

SERVIÇOS DE MAPEAMENTO

Em uma modalidade, um componente de mapeamento como 114 na figura 1 ge-rencia todos os aspectos de mapeamento e é utilizado internamente pelo provedor de clien-te de entidade 111. Um mapeamento especifica logicamente uma transformação entre cons-truções em dois espaços de tipo potencialmente diferentes. Por exemplo, uma entidade -em espaço conceptual, como esse termo é utilizado acima - pode ser especificada em ter-mos de tabelas de banco de dados em espaço de armazenagem, como ilustrado grafica-mente na figura 8.

Mapeamentos prescritos são aqueles onde o sistema determina, automaticamente,os mapeamentos apropriados para construções. Mapeamentos não prescritos permitem quedesigners de aplicação controlem várias facetas do mapeamento. Um mapeamento pode tervárias facetas. Os pontos finais do mapeamento (entidades, tabelas, etc.), o conjunto depropriedades mapeadas, o comportamento de atualização, efeitos de runtime como atrasode carga, o comportamento de resolução de conflito em atualizações, etc. são apenas umalista parcial de tais facetas.

Em uma modalidade, o componente de mapeamento 114 pode produzir visualiza-ções de mapeamento. Considere um mapeamento entre o espaço de armazenagem e oespaço de esquema. Uma entidade é composta de linhas a partir de uma ou mais tabelas. Visualizações de consulta expressam uma entidade no espaço de esquema como uma con-sulta em termos de tabelas em espaço de armazenagem. Entidades podem ser materializa-das por avaliação das visualizações de consulta.Quando alterações em um conjunto de entidades necessitam ser refletidas de voltapara as tabelas de armazenagem correspondentes, as alterações podem ser propagadasem modo inverso através das visualizações de consulta. Isso é similar ao problema de atua-lização de visualização em bancos de dados - um processo de propagação de atualizaçãoexecuta logicamente atualizações sobre o(s) inverso(s) da(s) visualização(ões) de consulta.

Para essa finalidade, os requerentes introduziram o conceito de visualizações de atualiza-ção - essas visualizações descrevem tabelas de armazenagem em termos de entidades, epodem ser pensadas como inversos da(s) visualização(ões) de consulta.

Em muitos casos, entretanto, os requerentes estão realmente interessados em alte-rações incrementais. Visualizações delta de atualização são visualizações (consultas) quedescrevem alterações em tabelas em termos de alterações em coleções de entidade cor-respondentes. O processamento de atualização para coleções de entidade (ou objetos deaplicação), compreende portanto, computar as alterações apropriadas em tabelas por avali-ar as visualizações delta de atualização, e então aplicar essas alterações nas tabelas.

Em um modo similar, Visualizações Delta de consulta descrevem alterações em co-leções de entidade em termos de alterações nas tabelas subjacentes. Invalidações, e maisgenericamente, notificações são cenários que podem exigir o uso de visualizações delta deconsulta.

Como com visualizações em bancos de dados, visualizações de mapeamento ex-pressas como consultas podem ser então compostas com consultas de usuário - levando aum tratamento mais generalizado de mapeamentos. Similarmente, visualizações delta demapeamento expressas como consultas permitem uma abordagem mais geral e elegante àsatualizações de manipulação.

Em uma modalidade, o poder das visualizações de mapeamento pode ser limitado.As construções de consulta utilizadas na visualização de mapeamento podem ser somenteum subconjunto de todas as construções de consulta que são suportadas pela estrutura deentidade. Isso permite expressões de mapeamento mais simples e mais eficientes - especi-almente no caso de expressões delta.

Visualizações delta podem ser computadas no componente de mapeamento 114 u-tilizando um esquema de computação de alteração algébrica para produzir as visualizaçõesdelta de atualização (e consulta) a partir das visualizações de atualização (e consulta). As-pectos adicionais do esquema de computação de alteração algébrica são discutidos posteri-ormente.

Visualizações delta de atualização permitem que uma Estrutura de Entidade supor-te atualizações traduzindo automaticamente alterações de entidade feitas por aplicações decomputação em atualizações de nível de armazenagem em um banco de dados. Em muitoscasos, entretanto, o mapeamento deve ser aumentado com informações adicionais paradesempenho e/ou integridade de dados.

Em alguns casos, o mapeamento direto de atualizações em entidades para algu-mas ou todas as suas tabelas de armazenagem subjacentes pode não ser desejável. Emtais casos, as atualizações devem ser afuniladas através de procedimentos armazenadospara permitir validação de dados bem como manter um limite de confiança. O mapeamentopermite que especificações de procedimentos armazenados manipulem atualizações e con-sultas através de entidades.

O mapeamento também pode fornecer suporte para controle de conformidade oti-mista nos serviços de objeto 131. Especificamente, propriedades de uma entidade podemser marcadas como campos de controle de conformidade como campo de versões ou mar-cas de tempo, e alterações nesses objetos somente terão sucesso se os valores dos cam-pos de controle de conformidade na armazenagem forem iguais na entidade. Observe queambos os campos de controle de conformidade-otimista são relevantes somente na camadade objeto de aplicação, não na camada específica de armazenagem 120.

Em uma modalidade, designers de aplicação podem utilizar a Linguagem de Espe-cificação de Mapeamento (MSL) para descrever vários aspectos de um mapeamento. Umaespecificação de mapeamento típica contém uma ou mais das seguintes seções.

1. a região de Dados pode conter descrições de classes, tabelas e/ou tipos deEDM. Essas descrições podem descrever tipos/tabelas/classes existentes, ou podem serutilizadas para gerar tais ocorrências. Valores gerados por servidor, limitações, chaves pri-márias, etc., são especificados como parte dessa seção.

2. a seção mapeamento descreve os mapeamentos efetivos entre os espaços de ti-po. Por exemplo, cada propriedade de uma entidade EDM é especificada em termos de umaou mais colunas a partir de uma tabela (ou conjunto de tabelas).

3. a região Runtime pode especificar vários nós que controlam a execução, por e-xemplo parâmetros de controle de conformidade otimista e estratégia de busca.

Compilador de mapeamento

Em uma modalidade, o componente de mapeamento de ferramenta de modelagemde domínio 172 pode compreender um compilador de mapeamento que compila especifica-ções de mapeamento em uma visualização de consulta, uma visualização de atualização eas visualizações delta correspondentes. A figura 9 ilustra a compilação de MSL para geraras Visualizações de Consulta e atualização.

A canalização de compilação executa as seguintes etapas:

1. O Gerador de visualização 902, chamado a partir do API 900, traduz as informa-ções de mapeamento de Objeto <->Entidade 901 (especificadas via MSL) e produz umavisualização de consulta, uma visualização de atualização e as expressões delta correspon-dentes (consulta e atualização) 904 no espaço O <->E (Objeto para entidade). Essas infor-mações podem ser colocadas na armazenagem de metadados 908.

2. O Gerador de visualização 906 traduz as informações de mapeamento de Enti-dade <-> Armazenagem 903 (especificadas via MSL) e produz uma visualização de consul-ta, uma visualização de atualização e as expressões delta correspondentes (consulta e a-

5 tualização) 907 no espaço E<-> S (Entidade para armazenagem). Essas informações po-dem ser colocadas na armazenagem de metadados 908.

3. O Componente de Análise de dependência 909 inspeciona as visualizações pro-duzidas pelo Gerador de visualização 906 e determina uma ordem de dependência consis-tente 910 para atualizações que não violam integridade referencial e outras tais limitações.Essas informações podem ser colocadas na armazenagem de metadados 908.

4. As visualizações, as expressões delta e a ordem de dependência 908 são entãopassadas sobre o componente de Serviços de metadados (112 na figura 1).

Processamento de atualização

Essa seção descreve a canalização de processamento de atualização. Em umamodalidade, a Estrutura de entidade pode suportar dois tipos de atualizações. Alterações deobjeto único são alterações feitas em objetos individuais enquanto navegam no gráfico deobjeto. Para alterações de objeto único, o sistema rastreia os objetos que foram criados,atualizados e deletados na transação atual. Isso é disponível somente na(s) camada(s) deobjeto(s). Alterações à base de consulta são alteradas executadas pela emissão de umainstrução de atualizar/deletar com base em uma consulta de objeto, por exemplo, como éfeito em bancos de dados relacionais para atualização de tabelas. Os Provedores de Objetocomo 131 na figura 1 podem ser configurados para suportar alterações de objeto único, po-rém não alterações baseadas em consulta. O Provedor de Cliente de entidade 111, por ou-tro lado, pode suportar alterações baseadas em consulta, porém não alterações de objetoúnico.

A figura 10 provê uma ilustração de processamento de atualização em uma modali-dade exemplar. Na figura 10, um usuário 1001 de uma aplicação na camada de aplicação1000 pode salvar alterações 1002 em dados manipulados por essa aplicação. Na camadade provedor de objeto 1010, uma lista de alterações é compilada 1011. O agrupamento dealteração 1012 é executado na lista de alteração. Manipulação de limitação 1013 pode pro-duzir informações de limitação e um modelo de dependência 1022 que é salvo na armaze-nagem de metadados 1017. Operações estendidas são executadas 1014. Uma expressãode controle de conformidade é gerada 1015, e um modelo de conformidade 1023 pode sersalvo na armazenagem de metadados 1017. O conversor de objeto em entidade 1016 podesalvar expressões delta de objeto em entidade 1024 para a armazenagem de metadados1017.

Uma árvore de expressão de entidade 1018 é passada para baixo para a camadade Provedor EDM 1030. Um divisor de atualização seletiva 1031 pode selecionar certas atu-alizações e dividir as mesmas conforme necessário. Um conversor de armazenagem EDM1032 pode salvar expressões delta de entidade-para-armazenar 1033 em uma armazena-gem de metadados 1036. Um componente de revelar visualização de consulta 1035 podesalvar visualizações de mapeamento de consulta 1035 para a armazenagem de metadados1036. Compensação de entidade para armazenagem 1037 é executada, e uma árvore deexpressão de armazenagem 1038 é passada para a camada de provedor de armazenagem1040.

Na camada de provedor de armazenagem 1040, um componente simplificador 1041pode operar primeiramente, seguido por um componente de geração SQL 1042, que geraatualizações de SQL 1043 a serem executadas no banco de dados 1044. Quaisquer resul-tados de atualizações podem ser passadas para um componente 1039 na camada de pro-vedor de EDM 1030 para manipular valores gerados por servidor. O componente 1039 podepassar resultados para cima para um componente similar na camada de provedor de objeto1021. Finalmente, quaisquer resultados ou confirmação de atualização 1003 são retornadosà camada de aplicação 1000.

Como descrito acima, visualizações delta de atualização são geradas como partede compilação de mapeamento. Essas visualizações são utilizadas nos processos de atuali-zação para identificar as alterações nas tabelas na armazenagem.

Para um conjunto de tabelas relacionadas na armazenagem, a Estrutura de Entida-de pode aplicar vantajosamente atualizações em uma certa ordem. Por exemplo, a existên-cia de limitações de chave estranha pode exigir que alterações sejam aplicadas em umaseqüência específica. A fase de análise de dependência (parte de compilação de mapea-mento) identifica quaisquer exigências de ordenação de dependência que podem ser com-putadas em tempo de compilar.

Em alguns casos, a técnica de análise de dependência estática pode não ser sufici-ente, por exemplo, com limitações de integridade referencial cíclica (ou limitações de integri-dade auto-referenciais). A Estrutura de Entidade adota uma abordagem otimista, e permiteque tais atualizações passem. Em runtime, se um ciclo for detectado, uma exceção é origi-nada.

Como ilustrado na figura 10, a canalização de processamento de atualização paraatualizações baseadas em ocorrência na camada de aplicação 1000 tem as seguintes eta-pas:

Agrupamento de alteração 1012: agrupa as alterações de acordo com as coleçõesde objeto diferentes a partir do rastreador de alterações, por exemplo, todas as alteraçõespara a coleção Pessoa são agrupadas em uma inserção, deleção e uma atualização defini-da para aquela coleção.Tratamento de limitação 1013: essa etapa executa quaisquer operações que com-pensam o fato de que nenhuma lógica comercial é executada sobre a camada de valor -essencialmente, permite que a camada de objeto estenda o conjunto de alterações. Com-pensação de deletar cascata e ordenação de dependência (para respeitar limitações EDM)são executadas aqui.

Execução de operação estendida 1014: as operações extra (por exemplo, deletar)são executadas de modo que a lógica comercial corresponder possa rodar.

Gerador de expressão de controle de conformidade 1015: para detectar se os obje-tos modificados estão antiquados, pode-se gerar expressões que verificam a coluna de mar-ca de tempo ou um conjunto de colunas como especificado nos metadados de mapeamento.

Conversão de objeto em EDM 1016: as listas de alteração especificadas em termosde conjuntos de inserir, deletar e atualizar objetos são agora convertidas utilizando expres-sões delta de mapeamento armazenadas na armazenagem de metadados 1017, que sãoarmazenadas após a compilação de mapeamento descrita com referência à figura 9. Apósessa etapa, as alterações são disponíveis como árvores de expressão 1018 expressas so-mente em termos de entidades EDM.

A árvore de expressão a partir da etapa 1018 é passada a seguir para o provedorEDM na Camada de provedor-EDM 1030. No provedor EDM, a árvore de expressão é pro-cessada e as alterações são submetidas à armazenagem. Observe que essa árvore de ex-pressão 1018 também pode ser produzida de outra maneira - quando uma aplicação pro-grama diretamente contra o provedor EDM, pode executar uma instrução DML contra amesma. Uma tal instrução DML é primeiramente convertida pelo provedor EDM em umaárvore de expressão EDM 1018. A árvore de expressão obtida a partir de uma instruçãoDML ou a partir da camada de aplicação 1000 é processada da seguinte maneira:

Divisor de atualização seletiva 1031: nessa etapa, algumas das atualizações sãodivididas em inserções e deleções. Em geral, propaga-se atualizações à medida que entramnas camadas inferiores. Entretanto, em certos casos, pode não ser possível executar taisatualizações, porque as regras de expressão delta não foram desenvolvidas para esse casoou porque a tradução correta resulta na realidade em inserções e/ou deleções nas tabelasde base.

Conversão de EDM em armazenagem 1032: a árvore de expressão de nível-EDM1018 é traduzida para o espaço de armazenagem utilizando as expressões delta a partir domapeamento apropriado.

Revelação de visualização de mapeamento de consulta 1034: a árvore de expres-são 1018 pode conter alguns conceitos de nível de EDM. Para eliminar os mesmos, os re-querentes revelam a árvore de expressão utilizando as Visualizações de mapeamento deconsulta 1035 para obter uma árvore 1038 em termos somente de conceitos de nível dearmazenagem. A árvore 1038 é opcionalmente processada por um componente de compen-sação E-S 1037.

A árvore de expressão 1038 que está agora em termos de espaço de armazena-gem é entregue agora ao provedor de armazenagem na camada de provedor de armazena-gem 1040 que executa as seguintes etapas:

Simplificação 1041: a árvore de expressão é simplificada utilizando regras de tradu-ção de expressão lógica.

Geração de SQL 1042: dada a árvore de expressão, o provedor de armazenagemgera a SQL efetiva 1043 a partir da árvore de expressão 1038.

Execução de SQL 1044: as alterações efetivas são executadas no banco de dados.

Valores gerados por servidor: valores gerados pelo servidor são retornados à ca-mada EDP 1030. O provedor 1044 passa os valores gerados por servidor para um compo-nente 1039 na camada 1030 que traduz os mesmos em conceitos EDM utilizando um ma-peamento. A camada de aplicação 1000 pega essas alterações 1003 e propaga as mesmaspara conceitos de nível de objeto a serem instalados nas várias aplicações e objetos utiliza-dos naquela camada.

Em muitos casos, as tabelas de armazenagem podem não ser diretamente atuali-záveis devido aos programas de Administrador de Banco de dados (DBA), por exemplo. Asatualizações em tabelas podem ser somente possíveis via procedimentos armazenados demodo que certas verificações de validação podem ser executadas. Em tais situações, ocomponente de mapeamento deve traduzir alterações de objeto em chamadas para essesprocedimentos armazenados em vez de executar instruções SQL de inserção, deleção eatualização "brutas". Em outros casos, os procedimentos "armazenados" podem ser especi-ficados no EDP 1010 ou na camada de aplicação 1000 - em tais casos, o componente demapeamento deve traduzir os objetos modificados em espaço EDM, e então chamar o pro-cedimento apropriado.

Para habilitar esses cenários, a MSL permite que procedimentos armazenados se-jam especificados como parte do mapeamento; adicionalmente, a MSL também suporta me-canismos para especificar como várias colunas de banco de dados são mapeadas para osparâmetros de procedimentos armazenados.

A camada EDP 1010 suporta controle de conformidade otimista. Quando o CDPenvia um conjunto de alterações para a armazenagem, as linhas alteradas já podem ter sidomodificadas por outra transação. O CDP deve suportar um modo para que os usuários se-jam capazes de detectar tais conflitos, e então resolver tais conflitos.

A MSL suporta mecanismos simples - marca de tempo, número de versão, colunasalteradas colunas - para detecção de conflito. Quando conflitos são detectados, uma exce-ção é originada, e os objetos conflitantes (ou entidades EDM) são disponíveis para resolu-ção de conflito pela aplicação.

EXIGÊNCIAS DE MAPEAMENTO EXEMPLAR

A infra-estrutura de mapeamento pode fornecer vantajosamente a capacidade detraduzir várias operações a partir do espaço de aplicação para o espaço relacionai, por e-xemplo, consulta de objeto gravadas por um desenvolvedor traduzidas para o espaço rela-cionai (armazenagem). Essas traduções devem ser eficientes sem cópia excessiva de da-dos. O mapeador pode fornecer traduções para as seguintes operações exemplares:

1. consultas: consultas de objeto necessitam ser convertidas no domínio relacionaiback-end e tuples obtido a partir do banco de dados necessitam ser convertidos em objetosde aplicação. Observe que essas consultas podem ser consultas baseadas em definição(por exemplo, CSQL ou seqüências C#) ou baseadas em navegação (por exemplo, acom-panhamento simples de referências).

2. atualizações: alterações feitas por uma aplicação em seus objetos necessitamser propagadas de volta para o banco de dados. Novamente, as alterações feitas nos obje-tos podem ser baseadas em definição ou em objetos individuais. Outra dimensão a conside-rar é se os objetos sendo modificados são totalmente carregados na memória ou parcial-mente carregados (Por exemplo, uma coleção pendurada em um objeto pode não estar pre-sente em memória). Para atualizações em objetos parcialmente carregados, desenhos nosquais esses objetos não necessitam ser totalmente carregados na memória, podem ser pre-feríveis.

3. Invalidações e notificações: as aplicações que rodam no nível médio ou nível decliente podem desejar ser notificadas quando alguns objetos mudam na backend. Dessemodo, o componente de mapeamento-OR deve traduzir registros no nível de objeto para oespaço relacionai; similarmente, quando as mensagens são recebidas por um cliente sobretuples modificados, o mapeador OR deve traduzir essas notificações em alterações de obje-to. Observe que WinFS suporta essas "notificações" via seu mecanismo Watcher - entretan-to, nesse caso, o mapeamento é determinado, ao passo que a Estrutura de Entidade devesuportar Watchers sobre um mapeamento não prescrito.

4. Um mecanismo similar a notificações também é necessário para invalidar objetosantiquados a partir de um processo de Estrutura de entidade que roda no nível de cliente oumédio - se a Estrutura de Entidade fornecer suporte para controle de conformidade otimistapara tratar de leituras/gravações conflitantes, aplicações podem assegurar que os dadoscached na Estrutura de entidade são razoavelmente novos (de modo que transações nãosão abortadas devido a leituras/gravações de objetos); de outro modo, podem tomar deci-sões sobre dados antigos e/ou ter suas transações abortadas posteriormente. Desse modo,como notificações, o mapeador OR pode ter de traduzir mensagens de "invalidação" a partirde servidores de banco de dados em invalidações de objeto.5. Backup/recuperar/sinc.: backup e espelhamento de Entidades são duas caracte-rísticas que podem ser incorporadas em algumas modalidades. As exigências para essascaracterísticas podem traduzir simplesmente em uma consulta especializada sobre Entida-des a partir da perspectiva de Mapeador OR; de outro modo, suporte especial para tais ope-rações pode ser fornecido. Similarmente, sinc. pode necessitar suporte a partir do motor demapeamento OR para traduzir as alterações de objeto, conflitos, etc., para a armazenageme vice-versa.

6. Participação em controle de conformidade: o mapeador OR pode suportar vanta-josamente modos diferentes pelos quais o controle de conformidade otimista pode ser utili-zado por uma aplicação, por exemplo, utilizando um valor de marca de tempo, algum con-junto específico de campos, etc. O Mapeador OR deve traduzir informações de controle deconformidade como propriedades de marca de tempo para/a partir do espaço de objeto e apartir de/para o espaço relacionai. O mapeador-OR pode até mesmo fornecer suporte paracontrole de conformidade pessimista (por exemplo, como Hibernar).

7. Relatório de erro de runtime. Na modalidade exemplar ilustrada aqui, erros deruntime ocorrerão normalmente no nível de armazenagem. Esses erros podem ser traduzi-dos no nível de aplicação. O mapeador OR pode ser utilizado para facilitar essas traduçõesde erro.

CENÁRIOS DE MAPEAMENTO

Antes de discutir cenários de desenvolvedor exemplares que uma Estrutura de en-tidade pode suportar, os requerentes ilustram várias partes lógicas do mapeador-OR. Emuma modalidade, há cinco partes em um mapeamento OR como ilustrado na figura 11:

1. Objetos/classes/XML (conhecido como espaço de aplicação) 1101: o desenvol-vimento especifica classes e objetos em uma linguagem escolhida - finalmente, essas clas-ses são compiladas em montagens CRL e são acessíveis através de APIs de reflexo. Essasclasses incluem membros persistentes e não persistentes também; além disso, detalhesespecíficos de linguagem podem ser incluídos nessa parte.

2. Esquema de modelo de dados de entidade (conhecido como espaço conceptual)1102: o espaço EDM é utilizado pelo desenvolvedor para modelar dados. Como discutidoacima, a especificação do modelo de dados é feita em termos de tipos EDM, relações entreentidades via associações, herança, e assim por diante.

3. Esquema de banco de dados (conhecido como espaço de armazenagem) 1103:nesse espaço, o desenvolvedor especifica como as tabelas são dispostas; limitações comolimitações de chave estranha e chave primária são também especificadas aqui. A especifi-cação nesse espaço pode tirar proveito de características específicas de vendedor, por e-xemplo tabelas aninhadas, UDTs, etc.

4. Mapeamento EDM-objeto 1104: esse mapeamento especifica como vários obje-tos e Entidades EDM se relacionam mutuamente, por exemplo, uma disposição pode sermapeada para uma associação de um-para-muitos. Observe que não é essencial que essemapeamento seja trivial/identidade, por exemplo, múltiplas classes podem mapear para umtipo EDM dado ou vice-versa. Observe que os requerentes podem ou não ter redundân-cia/desnormalização nesses mapeamentos (evidentemente, com desnormalização, é possí-vel ter problemas de manter os objetos/entidades consistentes).

5. Mapeamento de armazenagem-EDM 1105: esse mapeamento especifica comoas entidades EDM e tipos se referem a tabelas diferentes no banco de dados, por exemplo,estratégias de mapeamento de herança diferentes podem ser utilizados aqui.

Um desenvolvedor pode especificar um ou mais dos espaços 1101, 1102 ou 1103 eos mapeamentos correspondentes entre um ou mais mapeamentos entre eles. Se algumespaço de dados estiver faltando, o desenvolvedor pode dar dicas sobre como gerar esseespaço ou esperar que o EDP gere esses espaços automaticamente, com os mapeamentosprescritos correspondentes. Por exemplo, se um desenvolvedor especificar classes, tabelasexistentes, e um mapeamento entre elas, o EDP gera o esquema EDM interno e os mapea-mentos de Armazenagem-EDM e objeto-EDM correspondentes. Evidentemente, no casomais geral, o desenvolvedor pode ter controle total e especificar os modelos de dados nes-ses três espaços juntamente com os dois mapeamentos. A tabela abaixo mostra os diferen-tes cenários suportados no EDP. Essa é a lista exaustiva de casos onde o desenvolvedorpode especificar ou não objetos, entidades EDM, tabelas.

<table>table see original document page 38</column></row><table>

Dependendo dos cenários acima que o EDP deseja suportar, os requerentes terãode fornecer ferramentas para produzir os mapeamentos e espaços de dados não especifi-cados (em um modo prescrito ou baseado em dicas se forem fornecidas). O motor de ma-peamento OR interno assume que todas as 5 partes do mapeamento (objetos, especs. DeEDM, mapeamento OE, mapeamento ES) são disponíveis. Desse modo, o desenho de ma-peamento deve suportar o caso mais geral, isto é (G) na tabela acima.

LINGUAGEM DE ESPECIFICAÇÃO DE MAPEAMENTO

Uma das partes "visíveis" do mapeador OR a partir da perspectiva do desenvolve-dor é a Linguagem de Especificação de mapeamento ou a MSL - o desenvolvedor especifi-ca como várias partes do mapeamento se ligam mutuamente utilizando essa linguagem.Controles de runtime (por exemplo, busca de retardo, questões de controle de conformidadeotimista) são também especificados utilizando o MSL.

Os requerentes dividem o mapeamento em três conceitos diferentes - cada concei-to trata de uma preocupação diferente para o processo de mapeamento. Observe que nãomencionam se essas especificações são armazenadas em um único arquivo, múltiplos ar-quivos, ou especificadas através de um repositório externo (por exemplo, para a especifica-ção de dados).

1. Especificação de dados: nessa região, um desenvolvedor pode especificar asdescrições de classe, descrições de tabela, e descrições EDM. Essas descrições podem serfornecidas como especificações para fins de geração ou podem ser especificações paratabelas/objetos que já existem.

2. As especificações de objeto e tabela podem ser descritas em nosso formato oupodem ser importadas a partir de um repositório de metadados externo utilizando algumaferramenta de importação.

Observe que a especificação de valores gerados por servidor, limitações, chavesprimárias, etc., é feita nessa seção (por exemplo, na especificação EDM, limitações são es-pecificadas como parte da especificação do tipo).

2. Especificação de mapeamento: o desenvolvedor especifica mapeamentos paravários objetos, tipos EDM, e tabelas. Os requerentes permitem que desenvolvedores especi-ficam mapeamentos de Objeto-EDM, EDM-armazenagem, e objeto-armazenagem. Essaseção tenta ter redundância mínima com a especificação de dados.

Em todos os três casos de mapeamento (OS, ES e OS), os requerentes especifi-cam mapeamentos para cada classe "diretamente" no nível superior ou "indiretamente" den-tro de outra classe. Em cada mapeamento, um campo/propriedade é mapeado para outrocampo, função escalar de campos, um componente ou um conjunto. Para permitir atualiza-ções, esses mapeamentos necessitam ser bidirecionais, isto é, ir de objeto para o espaço dearmazenagem e de volta não deve perder nenhuma informação; os requerentes tambémpodem permitir mapeamentos não bidirecionais de tal modo que os objetos sejam somentelidos.

Mapeamentos de Objeto-EDM: em uma modalidade, os requerentes especificamum mapeamento para todo objeto em termos de tipos EDM.

Mapeamentos de EDM-armazenagem: em uma modalidade, os requerentes especi-ficam um mapeamento para toda entidade em termos de tabelas.

Mapeamentos de objeto-armazenagem: em uma modalidade, os requerentes espe-cificam um mapeamento para todo objeto em termos de tabelas.3. Especificação de runtime: em uma modalidade, os requerentes permitem quedesenvolvedores especifiquem vários nós que controlam a execução, por exemplo, parâme-tros de controle de conformidade otimista e estratégia de busca.

Aqui está um exemplo de um arquivo de mapeamento para um caso onde um obje-to Operson contém um conjunto de endereços. Esse objeto é mapeado para um tipo de En-tidade EDM e o conjunto é mapeado para um tipo de conjunto inline. Os dados são armaze-nados em duas tabelas - uma para as pessoas e a outra para endereços. Como menciona-do anteriormente, não é essencial que o desenvolvedor especifique todos os objetos, tiposEDM e tabelas - estamos mostrando apenas o caso (G) a partir da tabela acima. Não sesupõe que as especificações descrevem qualquer sintaxe específica; pretendem ilustrar ehabilitar desenho de um sistema em torno dos conceitos revelados aqui.

Especificações de objetos

Especificações EDM

Os requerentes especificam um tipo de entidade Cperson e um tipo inline Caddressde tal modo que cada Cperson tenha uma coleção de itens Caddress.

Especificações de armazenagem

Os requerentes especificam dois tipos de tabela Sperson e Saddress juntamentecom suas chaves (tpid e taid).

Mapeamentos de Objeto-CDM

O seguinte mapeamento para Operson diz que o tipo de objeto Operson é mapeadopara a Entidade Cperson. A lista após isso especifica como cada campo de Operson é ma-peado - nome é mapeado em nome e a coleção de addrs é mapeada para a coleção deendereço.<table>table see original document page 41</column></row><table>

Mapeamentos de EDM-armazenagem

O tipo de entidade EDM Cperson é mapeado para o tipo de tabela Sperson comseus atributos de cname de nome e chave. InIineType Caddress é mapeado para Saddressem um modo simples. Observe que a tabela Saddress pode armazenar uma chave estranhaem Sperson; essa limitação poderia ter sido especificada na especificação de modelo dedados da tabela, não no mapeamento.

Especificações de runtime

O desenvolvedor pode desejar especificar que controle de conformidade otimista noOperson seja feito nos campos pid e nome. Para Oaddress1 ele/ela pode especificar controlede conformidade no campo de estado.

VISÃO GERAL DE DESENHO DE MAPEAMENTO

A maioria das tecnologias de mapeamento OR1 como Hibernar e ObjectSpaces,têm uma desvantagem importante - manipulam atualizações em um modo relativamente ad-hoc. Quando alterações de objeto necessitam ser empurrada de volta para o servidor, osmecanismos utilizados por esses sistemas manipulam atualizações em uma base de caso acaso desse modo limitando a capacidade de extensão do sistema. Como mais casos demapeamento são suportados, a canalização de atualização se torna mais complexa e é difí-cil compor mapeamentos para atualizações. À medida que o sistema se desenvolve, essaparte do sistema se torna bem incômoda de alterar enquanto assegura que está correta.

Para evitar tais problemas, os requerentes utilizam uma abordagem nova onde e-xecutam o processo de mapeamento utilizando dois tipos de "visualizações de mapear" -um que os ajuda a traduzir consultas e o outro que ajuda a traduzir atualizações. Comomostrado na figura 12, quando uma especificação MSL 1201 é processada pelo EDP, geraduas visualizações 1202 e 1203 internamente para a execução do motor de mapeamento denúcleo. Como será visto posteriormente, por modelamento do mapeamento em termos des-sas visualizações, os requerentes são capazes de alavancar o conhecimento existente detecnologia de visualização materializada em bancos de dados relacionais - em particular,tiram proveito de técnicas de manutenção de visualização incrementais para modelar atuali-zações em um modo correto, elegante e extensível. Os requerentes discutem agora essesdois tipos de visualizações de mapeamento.

Os requerentes utilizam a noção de Visualizações de mapeamento de consulta ouQMViews para mapear dados de tabela em objetos e Visualizações de Mapeamento de atu-alização ou UMViews para mapear alterações de objeto em atualizações de tabela. Essasvisualizações são denominadas devido ao motivo (principal) pelo qual são construídas. AVisualização de consulta traduz consultas de objeto em consultas relacionais e converte ostuples relacionais de entrada em objetos. Desse modo, para o mapeamento de Armazena-gem-EDM, cada Qview mostra como um tipo EDM é construído a partir de várias tabelas.Por exemplo, se uma entidade Pessoa for construída a partir da junção de duas tabelas T_Pe T_A, os requerentes especificam Pessoa em termos de uma junção entre essas duas ta-belas. Quando uma consulta é solicitada na coleção Pessoa, o QMView para Pessoa substi-tui Pessoa com uma expressão em termos de T_P e T_A; essa expressão então gera a SQLapropriada. A consulta é então executada no banco de dados; quando uma resposta é rece-bida a partir do servidor, o QMView materializa os objetos a partir dos tuples retornados.

Para manipular atualizações de objeto, pode-se imaginar empurrar as alterações a-través de QMViews e alavancar a tecnologia de "atualização de visualização" desenvolvidapara bancos de dados relacionais. Entretanto, visualizações atualizáveis têm diversas restri-ções sobre as mesmas, por exemplo, Servidor SQL não permite que múltiplas tabelas debase sejam modificadas através de uma atualização de visualização. Desse modo, em vezde limitar os tipos de mapeamento permitidos no EDP1 as modalidades da invenção alavan-cam outro aspecto de tecnologia de visualização materializada que tem bem menos restri-ções - manutenção de visualização.

Os requerentes especificam Visualizações de mapeamento de atualização ou UM-Views para expressar cada tabela no sistema em termos de tipos EDM, isto é, em algumsentido, UMViews são o inverso de QMViews. Um UMView para um tipo de tabela no limiteEDM-armazenagem apresenta um modo pelo qual diferentes tipos de EDM são utilizadospara construir as colunas do tipo dessa tabela. Desse modo, se os requerentes especifica-ram que um tipo de objeto de Pessoa mapeia para tipos de tabela T_P e T_A, eles não ge-ram somente um QMView para o tipo de Pessoa em termos de T_P e T_A, geram tambémum UMView que especifica como uma linha de T_P pode ser construída dado um tipo deobjeto Pessoa (similarmente para T_A). Se uma transação criar, deletar ou atualizar algunsobjetos de pessoa, pode-se utilizar as Visualizações de Atualização para traduzir tais altera-ções a partir de objetos em instruções de inserção, atualização e deleção de SQL em T_P eT_A - o UMView ajuda a executar essas atualizações uma vez que informam sobre comotuples relacionais são obtidos a partir de objetos (via tipos de CDM). As figuras 13 e 14 mos-tram, em um nível alto, como QMViews e UMViews são utilizados em tradução de consulta eatualização.

Dada essa abordagem para modelar tabelas como visualizações em objetos, o pro-cesso de propagar atualizações em objetos de volta para tabelas é similar ao problema demanutenção de visualização onde objetos são as "relações de base" e as tabelas são as"visualizações". Há uma grande quantidade de literatura de banco de dados que trata doproblema de manutenção de visualização e pode-se alavancar a mesma para as finalidadesdos requerentes. Por exemplo, há uma quantidade significativa de trabalho que mostra co-mo alterações incrementais nas relações de base podem ser traduzidas em alterações in-crementais nas visualizações. Os requerentes utilizam uma abordagem algébrica para de-terminar as expressões necessárias para executar atualizações incrementais em visualiza-ções - eles se referem a essas expressões como expressões delta, utilizando uma aborda-gem algébrica, ao contrário de uma de procedimento, para manutenção de visualização in-crementai é apropriado uma vez que é mais favorável à otimização e simplificações de atua-lização.

Em geral, vantagens de utilizar visualizações de mapeamento no motor de núcleodo EDP incluem:

1. visualizações fornecem uma quantidade significativa de potência e flexibilidadepara expressar mapas entre objetos e relações. Pode-se iniciar com uma linguagem de ex-pressão de visualização restrita na parte de núcleo do motor de mapeamento OR. Comotempo e recursos permitem, a potência das visualizações pode ser utilizada para desenvol-ver graciosamente o sistema.

2. Visualizações são conhecidas como compondo de forma bem elegante com con-sultas, atualizações e as próprias visualizações. A capacidade de composição, especialmen-te com relação a atualizações, era uma questão problemática com algumas das abordagensde mapeamento OR tentada anteriormente. Por adotar uma tecnologia baseada em visuali-zação, pode-se evitar tais preocupações.

A utilização da noção de visualizações permite aos requerentes alavancam umaquantidade significativa de trabalho na literatura de banco de dados.

DISPOSIÇÃO EM CAMADAS DE ARQUITETURA PARA ATUALIZAÇÕES

Uma questão importante a considerar na implementação de aspectos da invenção équal é a capacidade da Linguagem de Visualização de Mapeamento (ou MVL) na qual Visu-alizações de Mapeamento de Consulta e Atualização são expressas. É quase potente o su-ficiente para capturar todos os mapeamentos não prescritivos entre os objetos e EDM jun-tamente com os mapeamentos entre o EDM e a armazenagem. Entretanto, para um MVLque suporta todos os conceitos CLR e EDM não relacionais de forma nativa, os requerentesnecessitam de projetar expressões delta ou incrementar regras de atualização de visualiza-ção para todas essas construções. Em particular, uma modalidade exemplar pode exigirregras de atualização para os conceitos/operadores de álgebra não relacionai a seguir:

Tipos complexos - acesso a partes de objetos, construtores tuple, alisamento,constantes complexas, etc.

Coleções - aninhamento e desaninhamento, alisamento/construção de conjunto,aplicação cruzada, etc.

Disposições/listas - ordenação de elementos não é uma construção relacionai; apa-rentemente, álgebras para listas ordenadas são bem complexas.

Outras construções EDM e construções de objeto no CLR/C# que necessitam sermodeladas.

É possível desenvolver expressões delta para atualizações incrementais para essasconstruções. O principal problema com o suporte de um grande conjunto de construções deforma nativa no MVL é que pode complicar o motor de núcleo consideravelmente. Em umamodalidade, uma abordagem mais desejável pode ser para dispor em camada o sistema detal modo que o "motor de mapeamento de núcleo" manipula um MVL simples e então disporem camada as construções não relacionais no topo desse núcleo. Os requerentes discutemum tal desenho agora.

A abordagem dos requerentes para mapeamento-OR trata dos problemas acimapor "dispor em camadas" - em tempo de compilação, primeiramente se traduz cada cons-trução não relacionai no objeto, EDM, e espaços de banco de dados (WinFS suporta ani-nhamento, UDTs, etc.) em uma construção relacionai correspondente em um modo prescritoe então executa as traduções não prescritas solicitadas entre as construções relacionais. Osrequerentes se referem a essa abordagem como a abordagem de mapeamento de visuali-zação em camadas. Por exemplo, se uma classe Cperson contiver uma coleção de endere-ços, os requerentes primeiramente traduzem essa coleção para uma construção relacionaicomo uma associação de um-para-muitos e então executam a tradução não prescrita solici-tada para tabelas no espaço relacionai.

Divisão de MVL

A MVL é dividida em duas camadas - uma que lida com o mapeamento não pres-critivo efetivo em termos relacionais e uma tradução prescritiva de construções não relacio-nais em termos relacionais. A linguagem anterior é mencionada como R-MVL (para MVL-relacional) e os mapeamentos correspondentes são denominados mapeamentos R-MVL;similarmente, a linguagem mencionada por último (mais poderosa) é mencionada como N-MVL (para MVL não relacionai) e os mapeamentos são denominados mapeamentos N-MVL.

Em uma modalidade, o mapeamento é fornecido por estruturar o desenho de talmodo que todas as construções não relacionais sejam empurradas para as extremidadesdas canalizações de consulta e atualização. Por exemplo, materialização de objeto podeenvolver a construção de objetos, disposições, ponteiros, etc. - tais "operadores" são em-purrados para o topo da canalização de consulta. Similarmente, quando atualizações ocor-rem em objetos, os requerentes traduzem alterações em objetos não relacionais (por exem-plo, coleções aninhadas, disposições) no início da canalização e então propagam essasalterações através da canalização de atualização. Em sistemas como WinFS, os requeren-tes necessitam de traduzir na extremidade da canalização de atualização para UDTs.

Por limitar os mapeamentos não prescritos a R-MVL1 os requerentes têm agora umpequeno conjunto de construções relacionais para os quais necessitam de regras de manu-tenção de visualização incrementais - tais regras já foram desenvolvidas para bancos dedados relacionais. Os requerentes se referem a construções/esquemas simplificados quesão permitidos no R-MVL como Esquema expresso de forma relacionai ou RES. Desse mo-do, quando alguma construção não relacionai necessita ser suportada (digamos) no domíniode objeto), os requerentes surgiram com uma construção RES correspondente e uma tradu-ção prescrita entre o objeto e a construção RES, por exemplo, os requerentes traduzemuma coleção de objeto para uma associação de um-para-muitos no espaço RES. Além dis-so, para propagar atualizações em uma construção não-relacional N, os requerentes surgi-ram com expressões delta que traduzem inserções, deleções e atualizações a partir de Npara N's correspondendo a construção RES. Observe que essas expressões delta são pres-critas e são geradas pelos requerentes em tempo de desenho, por exemplo, eles sabemcomo empurrar alterações para uma coleção sobre uma associação de um-para-muitos. Asexpressões deltas para os mapeamentos não prescritos efetivos são geradas automatica-mente utilizando regras de manutenção de visualização incrementai para bancos de dadosrelacionais. Essa metodologia em camadas não somente remove a exigência de surgir comregras de manutenção de visualização incrementai generalizadas para uma pletora de cons-truções não relacionais como também simplifica a canalização de atualização interna.

Observe que a abordagem de mapeamento em camadas dos requerentes tem umbenefício similar sobre a canalização de notificação também - quando alterações em tuplessão recebidas a partir do servidos os requerentes necessitam traduzir as mesmas em alte-rações incrementais em objetos. Essa é a mesma exigência que a canalização de atualiza-ção exceto que os requerentes necessitam de utilizar Visualizações de mapeamento deconsulta para propagar essas alterações, isto é, geram expressões delta para as QMViews.

Além de simplificar a canalização de notificações e atualização, a disposição emcamadas da MVL tem uma vantagem importante - permite que "linguagens superiores" (ob-jetos, EDM1 banco de dados) se desenvolvam sem ter um impacto significativo sobre o mo-tor de mapeamento de núcleo. Por exemplo, se um novo conceito for adicionado ao EDM1tudo que é necessário é surgir com um modo prescrito para converter isso em um RES cor-respondente para aquela construção. Similarmente, se um conceito não relacionai estiverpresente em Servidor SQL (por exemplo, UDTs1 aninhamento), pode-se traduzir esses con-ceitos no MVL em um modo prescrito e ter impacto mínimo sobre o MVL e motor de núcleo.Observe que a tradução entre RES-armazenagem e as tabelas de armazenagem não é ne-cessariamente uma tradução de identidade. Por exemplo, em sistemas back-end (como oWinFS back-end) que suporta UDTs1 aninhamentos, etc. a tradução é similar às relações deobjeto prescritas.

A figura 15 ilustra manipulação de tempo de compilar e runtime das visualizaçõesde mapeamento. Dado o modelo de dados e especificações de mapeamento na MSL comoilustrado por 1501, 1502 e 1503, os requerentes primeiramente gera os RESs corresponden-tes 1521, 1522 e 1523 para as construções não relacionais 1511, 1512, 1513, e as tradu-ções prescritas entre essas construções e os RESs, isto é, os mapeamentos N-MVL. A se-guir os requerentes geram as Visualizações de mapeamento de Consulta e Atualização,Objeto-EDM em R-MVL e EDM-Armazenagem em R-MVL1 para os mapeamentos não pres-critos solicitados pelos desenvolvedores - observe que essas visualizações de mapeamentooperam nos RESs utilizando a linguagem R-MVL. Nesse ponto, os requerentes geram asexpressões delta (expressões de manutenção de visualização) para as Visualizações demapeamento de consulta e atualização - tais regras foram desenvolvidas para construçõesrelacionais. Observe que expressões delta para QMViews são necessárias para fins de noti-ficações. Para os mapeamentos N-MVL, as expressões delta são determinadas em tempode desenho pelos requerentes uma vez que esses mapeamentos são prescritos, por exem-pio, quando mapeiam uma coleção de Endereços para uma associação de um-para-muitos,também projetam as expressões de manutenção de visualização correspondentes.

Dadas as visualizações e traduções acima (N-MVL e R-MVL), pode-se compor asmesmas para obter Visualizações de Mapeamento de consulta que podem expressar obje-tos 1531 em termos de tabelas na armazenagem 1533, e Visualizações de mapeamento deatualização que podem expressar tabelas 1533 em termos de objetos 1531. Como a figuramostra, pode-se escolher reter visualizações de mapeamento de tal modo que as EntidadesEDM em 1532 não são totalmente eliminadas a partir do mapeamento para runtime - ummotivo possível para manter essas visualizações é habilitar certos tipos de otimização deconsulta que tira proveito de limitações de EDM. Evidentemente, isso não significa que osrequerentes armazenam, na realidade, Entidades EDM em runtime.

A figura 16 mostra como os componentes diferentes obtêm o processo de compila-ção de visualização descrito acima. As aplicações chamam o API 1600. Os Geradores deVisualização 1601, 1603 são responsáveis por três funções: traduzir as construções nãorelacionais em construções RES1 gerar as Visualizações de Consulta/Atualização e gerar asexpressões delta para propagar atualizações e notificações. Podem utilizar metadados 1602na realização dessas funções. O meio de composição de Visualização OE 1605 toma o Ob-jeto e Informações EDM e compõe as mesmas de tal modo que os requerentes tenham ex-pressões algébricas de objetos em termos de tipos de EDM; similarmente, o Meio de Com-posição de Visualização ES 1606 produz expressões algébricas de tipos de EDM em termosde tabelas. Os requerentes compõem essas visualizações adicionalmente no meio de com-posição de visualização OS 1607 e obtém um conjunto único de visualizações na armaze-nagem de metadados 1608. Como discutido acima, os requerentes podem manter dois con-juntos de visualizações para oportunidades de otimização de consulta possíveis. Finalmen-te, um componente de análise de dependência 1604 pode operar também na saída de Ge-rador de Visualização ES para fornecer uma ordem de dependência para a armazenagemde metadados 1608.

Sumário de compilação de mapa

Para resumir, para cada especificação M de uma classe, tipo EDM, ou uma tabela,os requerentes geram os RESs correspondentes e as traduções prescritas entre Meo REScorrespondente. Desse modo, os requerentes geram o que se segue, como ilustrado na fi-gura 15:

1. RES correspondendo a M - indicado como RES-CDM(M), RES-objeto(M) ouRES-armazenagem(M)

2. Tradução prescrita para expressar cada especificação M em termos de relaçõesRES

3. tradução prescrita para expressar tal relação RES em termos de M

4. visualizações de mapeamento de consulta: há duas dessas visualizações - asQMViews OE expressam objetos em termos de tipos EDM e QMViews ES que expressamtipos de EDM em termos da armazenagem (tabelas)

5. Visualizações de mapeamento de atualização: há duas tais visualizações - UM-Views OE expressam tipos EDM em termos de objetos e UMViews ES que expressam astabelas de armazenagem em termos de tipos EDM.

6. Para manutenção incrementai de atualizações, os requerentes também geramexpressões delta nas U MViews.

Após composição dessas visualizações, os requerentes terminam com quatro ma-pas. Esses mapas são armazenados na armazenagem de metadados 1608 e são coletiva-mente mencionados como as Visualizações de Mapeamento compilado:

Mapas de consulta: expressam Objetos/CDM em termos de CDM/tabelas.

Mapas de atualização: expressam tabelas/CDM em termos de CDM/objetos.Expressões delta de atualização: expressam deltas em tabelas/CDM em termos dedeltas em CDM/tabelas.

Expressões delta de notificação: expressam deltas em objetos/CDM em termos dedeltas em CDM/tabelas.

Ordem de dependência: ordem na qual várias operações de inserção, deleção, atu-alização devem ser executadas em relações diferentes - essa ordem assegura que as limi-tações de banco de dados não são violadas durante o processo de atualização.

Exemplo de coleção

Os requerentes mostram agora brevemente as traduções prescritas e mapeamen-tos não prescritos para o exemplo de pessoa que estão considerando. Apresentam as Vi-sualizações de Mapeamento tanto de Consulta como de atualização - as expressões demanutenção de visualização correspondentes são discutidas adicionalmente abaixo.

RESs

Os requerentes traduzem Operson em uma construção RES R_Operson que sim-plesmente reflete o nome e pid; similarmente, traduzem Oaddress em R_Oaddresss. Paratraduzir a coleção de endereços, utilizam uma associação de um-para-muitosR_Operson_Address. Similarmente, para as construções EDM também. Os RESs para astabelas (R_Sperson, R_Saddress) são mapeamentos de identidade para Sperson e Sad-dress. Esses RESs são:

<table>table see original document page 48</column></row><table>

Visualizações de mapeamento de consulta

Os requerentes mostram o mapeamento de Objeto-armazenagem (composto atra-vés de mapeamentos de Objeto-EDM e EDM-armazenagem).Visualizações não prescritas em espaço RES

Os mapeamentos entre o objeto e espaço EDM são essencialmente de identidade.Todas as três visualizações R_Cperson, R_Caddress e R_Cperson_Address são simples-mente projeções em R_Sperson e R_Saddress.

<table>table see original document page 48</column></row><table>Tradução prescrita (objetos em termos de RES-objetos)

O objeto Operson é expresso utilizando R_Operson, R_Oaddress eR_Operson_Address fazendo uma junção de R_Operson_Address com R_Oaddress e ani-nhando o resultado.

<table>table see original document page 49</column></row><table>

Vista composta de Cperson

A expressão composta após simplificação pode ser (lembre que temos uma tradu-ção de identidade entre as tabelas e suas construções RES para esse exemplo):

<table>table see original document page 49</column></row><table>

A visualização final menciona o que se poderia esperar obter pelo uso de uma a-bordagem de mapeamento "direto". Uma vantagem da abordagem RES aparece quando seolha expressões delta para a canalização de atualização, e também na canalização de noti-ficação onde é necessário expressões delta para as Visualizações de mapeamento de con-sulta.

Visualizações de mapeamento de atualizaçãoVistas não prescritas em espaço RES

A UMView para R_Sperson é simplesmente uma projeção em R_Cperson ao passoque R_Saddress é construída pela junção de R_Caddress com a tabela de associação deum-para-muitos - R_Cperson_Address. O mapeamento entre o CDM e espaço de objeto éidentidade.

<table>table see original document page 49</column></row><table>

Tradução prescrita (RES-objetos em termos de Objetos)

É necessária a tradução dos objetos em RESs de modo que as atualizações pos-sam ser empurradas a partir do espaço de objeto para o espaço RES. A tradução prescritapara R_Operson é uma projeção simples ao passo que as traduções para R_Oaddress eR_Operson_Address são obtidas por execução de uma junção entre uma pessoa e seusendereços. Essa é uma "junção de pointer" ou uma "junção de navegação".

<table>table see original document page 50</column></row><table> Desse modo, a tabela Sperson pode ser expressa como uma projeção simples emOperson ao passo que Saddress é obtido por junção de Operson com seus endereços.Validação de visualização

Uma propriedade importante que as visualizações geradas necessitam atender éque devam ser "de viagem de ida e volta", isto é, para evitar qualquer perda de informação,devemos assegurar que quando uma Entidade/objeto que é salvo e então recuperado, nãohaja perda de informação. Em outras palavras, queremos assegurar para todas as entida-des/objetos D:

D = QMView(UMView(D))

Nosso algoritmo de geração de visualização assegura essa propriedade. Se essapropriedade for verdadeira, dizemos também que as "visualizações de consulta e atualiza-ção de viagem de ida e volta" ou são bidirecionais. Demonstramos agora essa propriedadepara o exemplo de pessoa-endereço. Para simplicidade, focalizamos na viagem de ida evolta no espaço RES.

Validação para R_Operson

Substituindo Sperson na visualização de consulta por Operson1 obtemos:

<table>table see original document page 50</column></row><table>

Simplificamos para obter

<table>table see original document page 50</column></row><table>

Isso é equivalente a SELECTFROM Person.Validação para Operson_Address

Para R_Operson_Adress, é levemente mais complicado. Temos:

R_Operson_Addres (pid, aid) = SELECT pid, aid FROM R_SaddressSubstituindo R_Saddress, obtemos:

Isto é simplificado como:

Para mostrar que o acima é realmente SELECT*FROM R_Operson_Address ne-cessitamos ter uma dependência de chave estranha R_Operson_Address.aid ->R_Oaddress.aid. Se essa dependência não for mantida, não podemos fazer a viagem de idae volta. É mantida no entanto uma vez que a gama da propriedade de valor definido addressé R_Oaddress. Essa limitação de chave estranha pode ser dita de duas maneiras:

Substituindo essa limitação na expressão acima nos fornece:

Validação para endereço

R_Oaddress é dado como:

Substituindo R_Saddress obtemos,

Isso pode ser dito novamente como:

Aqui, a junção com R_Operson_Address é redundante se a dependência de chaveestranha R_Oaddress.aid -> R_Operson_Address.aid for mantida. Essa dependência émantida somente se R_Oaddress for dependente de forma existencial em R_Operson (istoé, addrs é uma composição). Se não for verdadeiro, então nossas visualizações não farão aviagem de ida e volta. Desse modo, temos uma limitação:

Desse modo, obtemos a seguinte expressão:

TRADUÇÃO DE CONSULTA

Tradutor de consulta

O Tradutor de Consulta EDP (EQT) é responsável por traduzir consultas a partir deobjeto/espaço EDM em espaço de provedor utilizando os metadados de mapeamento. Asconsultas de usuário podem ser expressas em uma variedade de sintaxes, por exemplo,eSQL, Seqüências C#, VB SQL, etc. A arquitetura EQT é mostrada na figura 17. Descreve-10 mos agora os diferentes componentes do EQT.

O parser 1711 executa análise de sintaxe por parsing uma consulta de usuário ex-pressa em uma de várias formas - incluindo eSQL, Consulta integrada de Linguagem(LINQ), seqüências C#, e VB Sql. Quaisquer erros de sintaxe são detectados e indicadosnesse momento.

Para LINQ, a análise de sintaxe (e a análise semântica) é integrada às fases de a-nálise de sintaxe da própria linguagem (C#, VB, etc.). Para eSQL, a fase de análise de sin-taxe é uma parte do processador de consulta. Tipicamente há um analisador de sintaxe porlinguagem.

O resultado da fase de análise de sintaxe é uma árvore parse. Essa árvore é entãoalimentada para a fase de Análise Semântica 1712.

O componente de Analisador de semântica e Meio de vinculação de Parâmetro1712 gerencia parâmetros em consultas de usuário. Esse módulo rastreia os tipos de dadose valores de parâmetros na consulta.

A fase de Análise de semântica valida, de forma semântica, a árvore parse produzi-da pela fase de análise de sintaxe 1711. Quaisquer parâmetros na consulta já devem estarvinculados nesse momento, isto é seus tipos de dados devem ser conhecidos. Quaisquererros semânticos são detectados e indicados aqui; se bem sucedido, o resultado dessa faseé uma árvore semântica.

Observe que para LINQ, como mencionado anteriormente, a fase de análise se-mântica é integrada às fases de análise semântica da própria linguagem. Há tipicamente umanalisador semântico por linguagem uma vez que há uma árvore de sintaxe por linguagem.

A fase de análise semântica compreende logicamente o que se segue:

1. Resolução de nome: todos os nomes na consulta são resolvidos nesse momento.Isso inclui referências a extensões, tipos, propriedades de tipos, métodos de tipos, etc. Co-mo efeito colateral, os tipos de dados de tais expressões são também inferidos. Essa subfa-se interage com o componente de metadados.

2. Dedução e verificação de tipo: expressões na consulta são verificadas por tipo, eos tipos de resultado são inferidos.

3. Validação: outros tipos de validação ocorrem aqui. Por exemplo, em um proces-sador SQL, se um bloco de consulta contiver uma cláusula agrupar por, essa fase pode serutilizada para executar a restrição de que a lista de seleção pode somente se referir a cha-ves agrupar-por ou funções agregadas.

O resultado da fase de análise semântica é uma árvore semântica. Nesse momen-to, a consulta é considerada como sendo válida - nenhum erro semântico adicional deveocorrer a qualquer momento posteriormente durante compilação de consulta.

A fase de algebrização 1713 toma o resultado da fase de análise semântica 1712, econverte o mesmo em uma forma mais apropriada para transformações algébricas. O resul-tado dessa fase é uma árvore de operador relacionai estendido lógica, conhecido como ár-vore de álgebra.

A árvore de álgebra se baseia nos operadores de álgebra relacionais de núcleo -seleção, projeção, junção, união e estende isso com operações adicionais como ani-nhar/desaninhar e pivotar/não pivotar.

A fase de revelação de visualização 1714 do tradutor de consulta substitui, possi-velmente de forma recursiva, as expressões QMView para quaisquer objetos referenciadosna consulta de usuário. No final do processo de tradução de visualização obtém-se umaárvore que descreve a consulta em termos de armazenagem.

No caso da camada de objeto, a revelação de visualização pode ter sido feita todocaminho até o espaço de armazenagem (caso tivéssemos um mapeamento OS otimizadoarmazenado no repositório de metadados) ou a árvore de consulta pode ter sido transfor-mada para a camada EDM. No caso mencionado por último é necessário tomar essa árvoree realimentar a mesma para o componente de Revelação de visualização com a exigênciade que os conceitos EDM sejam agora traduzidos para os conceitos de armazenagem.

O componente Transformação/simplificação 1715 pode ser específico para prove-dor 1730, ou em uma modalidade alternativa pode ser um componente genérico-EDP quepode ser alavancado por vários provedores. Há alguns motivos para executar transforma-ções na árvore de consulta:

1. Operador empurrando para armazenagem: o EQT empurra operadores comple-xos (por exemplo, junção, filtro, agregado) para a armazenagem. De outro modo, tais opera-ções teriam de ser implementadas no EDP. A camada de materialização de valor do EDPsomente executa operações de "compensação não relacionais" como aninhamento. Se for-mos incapazes de empurrar um operador X para baixo dos nós de materialização de valorna árvore de consulta e a camada de materialização de valor não puder executar operaçãoX1 declaramos que a consulta é ilegal. Por exemplo, se a consulta tiver uma operação deagregação que não puder ser empurrada para o provedor, declaramos a consulta comosendo ilegal uma vez que a camada de materialização de valor não executa nenhuma agre-gação.

Desempenho aperfeiçoado: a complexidade reduzida da consulta é importante egostaríamos de evitar o envio de consultas gigantescas para a armazenagem back-end. Porexemplo, algumas das consultas atuais em WinFS são muito complexas e demoram muitotempo para executar (as consultas escritas a mão correspondentes são mais de uma ordemde magnitude mais rápida).

Capacidade de depuração aperfeiçoada: consultas mais simples também tornammais fácil para que o desenvolvedor depure o sistema e entenda o que está ocorrendo.

O módulo de transformação/simplificação 1715 pode transformar um pouco ou todaa árvore de álgebra representando a consulta em subárvores equivalentes. Observe queessas transformações baseadas em heurística são lógicas, isto é, não feitas utilizando ummodelo de custo. O tipo de transformações lógica pode inclui os seguintes serviços específi-cos de provedor exemplares:

Alisamento de subconsulta (subconsultas aninhada e de visualização)

Eliminação de junção

Eliminação e consolidação de predicado

Empurrar para baixo predicado

Eliminação de sub-expressão comum

Poda de projeção

Transformações de junção externa -> junção interna

Eliminação de correlação esquerda

Esse módulo de geração SQL 1731 faz parte do componente de provedor 1730uma vez que o SQL gerado é específico para o provedor. Após simplificação, a árvore deálgebra é passada para o provedor que pode executar ainda transformações específicas deprovedor ou simplificações antes da geração do SQL apropriado.

Após a consulta executar no servidor, os resultados são fluidos para o cliente EDP.

O provedor 1730 expõe DataReaders que podem ser utilizados por uma aplicação para ob-ter os resultados como Entidades EDM. O serviço de materialização de valor 1741 podetomar esses leitores e converter os mesmos em Entidades EDM relevantes (como novosdatareaders). Essas entidades podem ser consumidas por uma aplicação ou os novos Da-taReaders podem ser passados para um serviço de materialização de objeto superior.

O EQT 1700 representa materialização como um operador na árvore de consulta.Isso permite que a canalização de tradução de consulta regular produza objetos no espaçoEDM, que pode então ser alimentado diretamente para usuários, em vez de exigir opera-ções fora-de-faixa especiais para executar a materialização efetiva. Isso também permiteque várias otimizações como busca de objeto parcial, carga impulsiva, etc. sejam executa-das nas consultas de usuário.

Exemplo de consulta

Considere o exemplo Pessoa-Endereço que estamos desenvolvendo. Suponha queo usuário deseja rodar a seguinte consulta - encontrar todas as pessoas em WA. Podemosgravar essa consulta em pseudo-CSQL como:

Se fizermos revelação de visualização utilizando a Visualização de Consulta paraPessoa nesse ponto, obtemos:

Essa consulta pode ser simplificada antes de enviar para o servidor back-end:

Metadados

O EQT requer vários pedaços de metadados durante a compilação e execução deuma consulta. Esses metadados incluem

Metadados de espaço de aplicação: informações sobre Extensões/coleções, tipos,propriedades de tipo, métodos de tipo exigidos durante análise semântica para validar con-sultas de usuário.

Metadados de espaço-esquema: informações sobre coleções de entidade, Tipos deCDM e propriedades necessárias durante compilação de visualização. Informações sobrerelações entre entidades e limitações sobre entidades para transformações.

Metadados de armazenagem-espaço: como descrito acima.

Mapeamentos de Aplicação -> esquema: Árvore de Operador Lógico representandodefinição de visualização necessária para expansão de visualização.

Mapeamentos de esquema -> armazenagem: como descrito acima.

Canalização de relatório de erro

Os erros em vários estágios de processamento de consulta devem ser reportadosem termos compreensíveis pelo usuário. Vários erros de compilação e tempo de execuçãopodem ocorrer durante processamento de consulta. Erros durante análise de sintaxe e se-mântica estão na maior parte em espaço de aplicação, e exigem muito pouca manipulaçãoespecial. Erros durante transformações são na maior parte erros de recurso (fora de memó-ria, etc.) e necessitam algum tratamento especial. Erros durante geração de código e execu-ção de consulta subseqüente podem necessitar ser apropriadamente processados. Um de-safio chave em relatório de erro é mapear erros de runtime que ocorrem em níveis mais bai-xos de abstração para erros que são significativos no nível de aplicação. Isso significa que énecessário processar erros de nível mais baixo através de mapeamentos de armazenagem,conceptual e aplicação.

Exemplo de consulta

Nossa consulta OO de amostra busca o nome de todas as pessoas que têm ende-reço em Washington:

Etapa 1: conversão em termos relacionais

Essa consulta pode ser convertida na seguinte consulta puramente relacionai ex-pressa em termos de R_Operson, R_Operson_Address, e R_Oaddress. Essencialmente,estamos expandindo as várias propriedades de navegação (expressão "." Ponto) para ex-pressões de junção se necessário.

SELEGT-piiaa^r

Observe que a consulta está ainda no domínio de objeto e em termos das exten-sões de objeto.

Etapa 2: revelação de visualização: conversão em espaço de armazenagem

Etapa 3: simplificação de consulta

Pode-se aplicar agora uma série de transformações lógicas para simplificar essaconsulta.(aid) e obter:

Agora, pode-se eliminar a auto-junção redundante na chave primária de Saddress

Tudo acima é relativamente direto. Temos agora uma consulta que pode ser envia-da para Servidor SQL.

PROCESSAMENTO DE TEMPO DE COMPILAÇÃO PARA ATUALIZAÇÕES

O EDP permite que aplicações criem novos objetos, atualize os mesmos, delete osmesmos e então armazene essas alterações de forma persistente. O componente de mape-amento OR necessita assegurar que essas alterações são traduzidas corretamente em alte-rações de armazenagem back-end. Como discutido anteriormente, utilizamos Visualizaçõesde mapeamento de Atualização que declaram uma tabela em termos de objetos. Utilizandotais visualizações, reduzimos essencialmente o problema de propagação de atualização emum problema de manutenção de visualização materializado onde mudanças em relações debase necessitam ser propagadas para as visualizações; no caso de UMViews, as "relaçõesde base" são objetos e as "visualizações" são as tabelas. Por modelar o problema dessemodo, podemos alavancar o conhecimento da tecnologia de manutenção de visualizaçãoque foi desenvolvido no mundo de banco de dados relacionais.

Geração de visualização de mapeamento de atualização

Como no caso de consulta, muito trabalho de mapeamento para atualizações é e-xecutado em tempo de compilação. Juntamente com os Esquemas expressos de forma re-lacional para as classes, tipos EDM, e tabelas, geramos as traduções prescritas entre essestipos e as construções RES correspondentes. Geramos também as Visualizações de Mape-amento de atualização entre as construções RES de classes e Tipos EDM e entre as cons-truções RES dos tipos EDM e tabelas de armazenagem.

Deixe-nos entender essas UMViews com o auxílio do exemplo de Pessoa-endereçoque estamos desenvolvendo. Lembre as construções RES para objetos (R_Operson,R_Oaddress, R_Operson_Address) que foram construídas.

Visualizações de mapeamento de atualização (RES de tabelas em termos de RESde objetos)

A UMView para R_Operson é simplesmente uma projeção em R_Sperson ao passoque R_Saddress é construído pela junção de R_Oaddress com a tabela de associação deum-para-muitos - R_Operson_Address.Traduções prescritas (RES em termos de objetos)

É necessário traduzir os objetos em RESs de modo que as atualizações possamser empurradas a partir do espaço de objeto para o espaço RES. Utiliza-se a função uo2r"para traduzir o endereço de memória virtual de um objeto para as chaves pid e aid - na im-plementação pode-se simplesmente pegar as chaves a partir do estado sombreado do obje-to. A tradução prescrita para R_Operson é uma projeção simples ao passo que as traduçõespara R_Oaddress e R_Operson_Address são obtidas por execução de uma junção entreuma pessoa e seus endereços.<table>table see original document page 58</column></row><table>

Visualizações de mapeamento de atualização compostas

Os requerentes compuseram as visualizações acima (e com alguma simplificação)para obter as seguintes visualizações de mapeamento de atualização compostas:

<table>table see original document page 58</column></row><table>

Desse modo, a tabela Sperson pode ser expressa como uma projeção simples emOperson ao passo que Saddress é obtido pela junção de um Operson com seus endereços.

Geração de expressão delta

Quando uma aplicação pede que suas alterações de objeto sejam salvas paraback-end, as modalidades podem traduzir essas alterações para a armazenagem back-end,isto é, podem gerar expressões delta para as tabelas (visualizações) em termos das expres-sões delta dos objetos (relações de base). Essa é a área onde a divisão do processo decompilação/geração de visualização nas construções RES realmente ajuda. As expressõesdelta para os mapeamentos não prescritos podem ser geradas com facilidade relativa umavez que esses mapeamentos estão no espaço relacionai (RESs são puramente relacionais)e muito trabalho em bancos de dados relacionais foi feito para se obter esse objetivo. Porexemplo, na literatura de banco de dados, regras de expressão delta foram desenvolvidaspara visualizações que são expressas em termos de operadores relacionais como seleções,projeções, junções interna ou externa ou semi-junções, uniões, interseções e diferenças.Para as construções não relacionais, só é necessário projetar expressões delta prescritasque convertem as construções não relacionais para/a partir do espaço RES.

Deixe-nos entender as expressões delta com nosso exemplo de Pessoa. Considereo caso onde uma construção RES (por exemplo, R_Saddress) é expressa como uma junçãode duas coleções de objeto (R_Oaddress e R_Operson_Address). A expressão delta parauma tal visualização pode ser obtida utilizando as seguintes regras (suponha que a visuali-zação de junção é V = R JOIN S):

<table>table see original document page 59</column></row><table>

Nessa expressão, i(X) e d(X) indicam os tuples inserido e deletado para a relaçãoou visualização X e Rnew indica o novo valor das relações de base R após aplicar todas assuas atualizações.

Desse modo, para facilitar atualizações em runtime, uma modalidade exemplar po-de gerar primeiramente as seguintes expressões delta em tempo de compilação:

1. expressões de alteração delta prescritas 1803 para relações RES 1811 em ter-mos de expressões de alteração delta para grupos de coleções de objeto atualizadas 1801,por exemplo, i(R_Operson) em termos de i(Operson).

2. expressões de alteração delta prescritas 1804 para as tabelas 1802 em termosde expressões de alteração delta para relações RES 1812, por exemplo, i(Sperson) em ter-mos de i(R_Sperson).

3. expressões delta 1813 para relações RES de tabelas expressas em termos deexpressões delta de relações RES de objetos, por exemplo, i(R_Sperson) em termos dei(R_Operson).

Podemos compor (1), (2) e (3) para obter uma expressão delta 1820 para as tabe-las 1822 (por exemplo, Sperson) em termos de expressões delta para objetos 1821 (porexemplo, Operson). Essa composição é ilustrada na figura 18. Desse modo, como no casode consultas, em tempo de compilação, temos agora uma tradução direta a partir de objetospara tabelas. No caso de atualizações, realmente nós alavancamos a divisão RES para ge-rar as expressões delta (para as QMViews, essa vantagem é aplicável para notificações).

Observe que não é necessário ser expressões delta para atualizações - como ve-remos posteriormente, atualizações de modelo podem ser modeladas colocando as mesmasno conjunto de inserção e deleção; uma etapa de pós-processamento reconverte posterior-mente os mesmos de volta em atualização antes que as alterações sejam efetivamente apli-cadas ao banco de dados. Um motivo para essa abordagem é que trabalho existente sobremanutenção de visualização incrementai não tem tipicamente expressões delta para atuali-zações. Alternativamente, modalidades mais completas nas quais tais expressões são de-senvolvidas são exeqüíveis.

Após a composição de visualização ter sido executada, as expressões delta para astabelas podem ser puramente em termos das coleções de objeto e conjuntos de inserção edeleção de objetos, por exemplo, i(Sperson) são termos de Operson, i(Operson) ed(Operson). Algumas dessas expressões delta podem necessitar que coleções de objetosejam computadas, por exemplo, i(Operson) necessita Eperson para sua computação. En-tretanto, a coleção inteira pode não ser cached no cliente EDP (ou podemos querer rodar aoperação no valor mais consistente e mais recente da coleção). Para tratar desse problema,revelamos as coleções de objeto utilizando as Visualizações de mapeamento de consultacorrespondentes, por exemplo, utilizamos a QMView para Operson e expressamos a mes-ma em termos de Sperson e outras relações se necessário. Desse modo, em uma modali-dade, ao término do processo de compilação, todas as expressões delta para Sperson sãoexpressas em termos de i(Operson), d(Operson), e a própria relação Sperson - em runtime,dados os conjuntos de inserção e deleção de Operson, podemos gerar agora as instruçõesde SQL relevantes que podem ser executadas no servidor.

Em resumo, dadas as QMViews e UMViews entre construções RES de tabelas eobjetos e as traduções prescritas entre essas construções e as tabelas/objetos, as seguintesetapas exemplares podem ser realizadas:

1. gerar as expressões delta mencionadas nas etapas 1, 2 e 3 acima.

2. compor essas expressões de tal modo que tenhamos as expressões delta paraas tabelas (Sperson) em termos de expressões delta dos objetos (Operson) e as própriascoleções de objeto.

3. revelar as coleções de objetos utilizando suas QMViews para obter expressõesdelta para tabelas (Sperson) em termos das expressões delta dos objetos e as próprias ta-belas, isto é, coleções de objeto são eliminadas. Podem existir casos especiais que permi-tem que modalidades evitem essa revelação ou saibam que a coleção inteira está cachedno cliente.

4. Simplificar/otimizar a expressão de modo que reduza o trabalho de runtime.

Além das implementações específicas expostas explicitamente aqui, outros aspec-tos e implementações serão evidentes para aqueles versados na técnica a partir da conside-ração do relatório descritivo revelado aqui. Pretende-se que o relatório descritivo e imple-mentações ilustradas sejam considerados somente como exemplos, com um verdadeiroescopo e espírito das reivindicações que se seguem.

Claims (20)

1. Método para fornecer serviços de dados para uma aplicação, CARACTERIZADOpor compreender:gerar uma visualização de consulta 1302 que expressa pelo menos uma porção deum esquema de aplicação associado à aplicação em termos de um esquema de banco dedados associado a um banco de dados;gerar uma visualização de atualização 1412 que expressa pelo menos uma porçãodo esquema de banco de dados em termos do esquema de aplicação;utilizar a visualização de consulta para consultar o banco de dados 1303 em nomeda aplicação solicitante;utilizar a visualização de atualização para atualizar o banco de dados 1414 em no-me da aplicação solicitante.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreenderainda receber 1411, a partir da aplicação solicitante, um objeto em uma linguagem de pro-gramação, o objeto em uma linguagem de programação compreendendo dados para uso naatualização do banco de dados.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreenderainda receber 1411, a partir da aplicação solicitante, uma instrução criar, inserir, atualizar oudeletar, a instrução criar, inserir, atualizar ou deletar compreendendo dados para utilizar naatualização do banco de dados.

4. Método, de acordo com a reivindicação 1, CARACTERIZADO por compreenderainda receber 1411, a partir da aplicação solicitante, uma expressão em uma Linguagem deManipulação de dados (DML), a expressão compreendendo dados para uso na atualizaçãodo banco de dados.

5. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que autilização da visualização de atualização para computar uma atualização para o banco dedados compreende aplicar um algoritmo de manutenção de visualização na visualização deatualização.

6. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que aaplicação de um algoritmo de manutenção de visualização na visualização de atualizaçãoproduz uma expressão delta para a visualização de atualização, e compreende ainda utilizara revelação de visualização 1715 para combinar a expressão delta com uma visualização deconsulta.

7. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que autilização da visualização de atualização para computar uma atualização para o banco dedados compreende aplicar um algoritmo de manutenção de visualização para dados recebi-dos para uso na atualização do banco de dados.

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que oesquema de aplicação suporta classes, relações, herança, agregação e tipos complexos.

9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que avisualização de atualização é gerada utilizando mapeamento que correlaciona o esquemade aplicação com o esquema de banco de dados.

10. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de quea visualização de consulta e a visualização de atualização são geradas utilizando o mapea-mento.

11. Sistema de acesso a dados para fornecer serviços de dados a uma aplicação,CARACTERIZADO por compreender:um componente 110 para gerar uma visualização de consulta que expressa pelomenos uma porção de um esquema de aplicação associado à aplicação em termos de umesquema de banco de dados associado a um banco de dados;um componente 110 para gerar uma visualização de atualização que expressa pelomenos uma porção do esquema de banco de dados em termos do esquema de aplicação;um componente 113 para utilizar a visualização de consulta para consultar o bancode dados em nome da aplicação solicitante;um componente 113 para utilizar a visualização de atualização para atualizar obanco de dados em nome da aplicação solicitante.

12. Arquitetura de acesso a dados, de acordo com a reivindicação 11,CARACTERIZADO por compreender ainda um componente 113 para receber a partir daaplicação solicitante, um objeto em uma linguagem de programação, o objeto em uma lin-guagem de programação compreendendo dados para uso na atualização do banco de da-dos.

13. Arquitetura de acesso a dados, de acordo com a reivindicação 11,CARACTERIZADO por compreender ainda um componente 113 para receber, a partir daaplicação solicitante, uma instrução de criar, inserir, atualizar ou deletar, a instrução de criar,inserir, atualizar ou deletar compreendendo dados para utilizar na atualização do banco dedados.

14. Arquitetura de acesso a dados, de acordo com a reivindicação 11,CARACTERIZADO por compreender ainda um componente 113 para receber a partir daaplicação solicitante, uma expressão em uma Linguagem de Manipulação de dados (DML),a expressão compreendendo dados para uso na atualização do banco de dados.

15. Arquitetura de acesso a dados, de acordo com a reivindicação 11,CARACTERIZADO pelo fato de que o componente 113 para utilizar a visualização de atua-lização para computar uma atualização para o banco de dados aplica um algoritmo de ma-nutenção de visualização na visualização de atualização.

16. Arquitetura de acesso a dados, de acordo com a reivindicação 15,CARACTERIZADO pelo fato de que a aplicação de um algoritmo de manutenção de visuali-zação na visualização de atualização produz uma expressão delta para a visualização deatualização, e compreende ainda um componente 113 para utilizar a revelação de visualiza-ção para combinar a expressão delta com uma visualização de consulta.

17. Arquitetura de acesso a dados, de acordo com a reivindicação 11,CARACTERIZADO pelo fato de que o componente 113 para utilizar visualização de atuali-zação para computar uma atualização para o banco de dados aplica um algoritmo de manu-tenção de visualização para dados recebidos para uso na atualização do banco de dados.

18. Arquitetura de acesso a dados, de acordo com a reivindicação 11,CARACTERIZADO pelo fato de que o esquema de aplicação suporta classes, relações,herança, agregação e tipos complexos.

19. Arquitetura de acesso a dados, de acordo com a reivindicação 11,CARACTERIZADO por compreender ainda um componente 114 para gerar mapeamentoque correlaciona o esquema de aplicação com o esquema de banco de dados.

20. Arquitetura de acesso a dados, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de que a visualização de consulta e a visualização de atualiza-ção são geradas utilizando o mapeamento.