MX2008011651A - Arquitectura de mapeo con movimiento de vista incrementada. - Google Patents

Abstract

Se proporciona una arquitectura de acceso de datos que incluye una arquitectura de mapeo para mapear datos, tal como puede ser utilizada por una aplicación a datos como persisten en una base de datos. La arquitectura de mapeo hace uso de dos tipos de vistas de mapeo - una vista de solicitud que ayuda a traducir solicitudes y una vista de actualización que ayuda a traducir actualizaciones. Se puede utilizar el mantenimiento de vista incremental para traducir datos entre la aplicación y la base de datos.

Description

ARQUITECTURA DE MAPEO CON MANTENIMIENTO DE VISTA INCREMENTADA Antecedentes de la Invención Las aplicaciones de puenteo y las bases de datos es un problema que ha existido durante mucho tiempo. En 1996, Carey y DeWitt señalaron porque muchas tecnologías, incluyendo bases de datos orientadas por objetos y lenguajes de programación persistentes, no ganaron una amplia aceptación debido a limitaciones en el procesamiento de solicitudes y actualización, rendimiento de la transacción y capacidad de escalado. Ellos especularon que las bases de datos de objeto-relación (O/R) podrían dominarse en el 2006. De hecho, los sistemas de base de datos DB2® y Oracle® incluyen una capa de objeto incorporada que utiliza un mapeo O/R cableado en la parte superior de un procesador de relación convencional. Sin embargo, las características O/R ofrecidas por estos sistemas parecen ser raramente utilizadas para almacenar datos de empresas, con la excepción de tipos de datos de multimedia y de espacio. Entre las razones está la independencia de los datos y el proveedor, el costo de emigrar bases de datos de legado, dificultades de escalado cuando la lógica del negocio corre dentro de la base de datos en lugar de la hilera media, y la integración insuficiente con lenguajes de programación.

Desde mediados de los 1990's, las capas de mapeo de datos en la parte del cliente han ganado popularidad, alimentados por el crecimiento de aplicaciones de Internet. Una función central de dicha capa, es proporcionar una vista actualizable que expone un modelo de datos alineado en forma cercana con el modelo de datos de la aplicación, conducida por un mapeo explícito. Muchos productos comerciales y proyectos de fuente abierta, han surgido para ofrecer estas capacidades. Virtualmente cada estructura de empresas proporciona una capa de persistencia en la parte del cliente (por ejemplo, EJB en J2EE). La mayor parte de las aplicaciones de negocios empacadas, tales como aplicaciones ERP y CRM, incorporan interfases de acceso de datos de propiedad (por ejemplo, BAPI en SAP R/3). Una fuente abierta utilizada ampliamente, la estructura de Mapeo de Relación de Objetos (ORM) para Java® es Hibernate®. Ésta soporta un número de escenario de mapeo heredados, control de concurrencia optimista y servicios de objetos de comprensión. La última liberación de Hibernate se conforma con el estándar EJB 3.0, el cual incluye el Lenguaje de Solicitud de Persistencia de Java. En la parte comercial, los ORMs populares incluyen Oracle TopLink® y LLBLGen®. Este último corre en la plataforma.NET. Estos y otros ORMs están acoplados estrechamente con los modelos de objeto de estos lenguajes de programación objetivo.

BEA® introdujo recientemente un nuevo producto de software que conecta dos diferentes aplicaciones pro separado (middleware), denominado AquaLogic Data Services Platform® (ALDSP). Éste utiliza el esquema XML para modelar los datos de la aplicación. Los datos XML son ensamblados utilizando XQuery de bases de datos y servicios Web. El tiempo de corrida de ALDSP soporta solicitudes a través de múltiples fuentes de datos y lleva a cabo la optimización de solicitud en la parte del cliente. Las actualizaciones se llevan a cabo como actualizaciones de vista en las vistas XQuery. Si una actualización no tiene una traducción única, el desarrollador necesita dominar la lógica de actualización utilizando un código imperativo. La superficie de programación de ALDSP está basada en los objetos de datos de servicio (SDO). Las capas de mapeo en la parte del cliente actuales, ofrecen grados ampliamente diversos de capacidad, robustez y costo total de la propiedad. Normalmente, el mapeo entre los artefactos de la aplicación y la base de datos utilizados por ORMs, tiene semánticas vagas y conduce a un razonamiento caso por caso. Una implementación conducida por el escenario limita el rango de mapeo soportados y con frecuencia produce un tiempo de corrida frágil que es difícil de extender. Algunas soluciones de acceso de datos, apalancan técnicas de transformación de datos desarrolladas por la comunidad de la base de datos, y con frecuencia dependen de soluciones ad hoc para la traducción de solicitudes de actualización. La investigación de base de datos ha contribuido a que muchas técnicas poderosas puedan ser apalancadas para construir capas de persistencia. Y aún así, existen brechas significativas. Entre las más importantes, está el soporte de actualizaciones a través de los mapeos. En comparación con las solicitudes, las actualizaciones son más difíciles de tratar, ya que necesitan conservar la consistencia de datos a través de mapeos, pueden activar reglas de negocios, etc. Como consecuencia, los sistemas de base de dato comerciales y los productos de acceso de datos ofrecen un soporte muy limitado para las vistas actualizables. Recientemente, los investigadores han volteado a métodos alternativos, tal como transformaciones bi-direccionales. Tradicionalmente, el modelado conceptual ha sido limitado al diseño de base de datos de aplicación, ingeniería inversa, y traducción de esquemas. Muchas herramientas de diseño utilizan UML. Únicamente el modelado conceptual muy reciente, comenzó a penetrar soluciones de mapeo de datos de refuerzo para la industria. Por ejemplo, el concepto de superficie de entidades y relaciones tanto en ALDSP como en EJB 3.0. ALDSP, cubre las relaciones E-R-style en la parte superior de datos XML categorizados-complejos, en tanto que EJB 3.0 permite especificar relaciones entre objetos utilizando anotaciones de clase.

Se utilizan técnicas de mapeo de esquema en muchos productos de integración de datos, tal como en herramientas Microsoft® BizTalk Server®, IBM® Rational Data Architect®, y ETL®. Estos productos permiten a los desabolladores diseñar transformaciones de datos, o compilarlas a partir de mapeos para traducir mensajes de comercio-electrónico o cargar almacenes de datos. Breve Descripción de la Invención Se proporciona sistemas, métodos y medios legibles en computadora para la implementación y uso de una arquitectura de acceso de dato que incluye una arquitectura de mapeo para mapear datos, tal como se puede utilizar a través de una aplicación para datos, tal como persiste en una base de datos. En una modalidad, la arquitectura de mapeo hace uso de dos tipos de vistas de mapeo-una vista de solicitud de ayuda a traducir las solicitudes de una vista de actualización que ayuda a traducir las actualizaciones. Se puede utilizar un mantenimiento de vista en incremento, para traducir datos entre la aplicación y la base de datos. A continuación se describen aspectos y modalidades adicionales. Breve Descripción de los Dibujos Los sistemas y métodos de arquitectura de mapeo con mantenimiento de vista en incremento, de acuerdo con la presente invención se describen en forma adicional con referencia a los dibujos adjuntos en los cuales: La figura 1, ilustra una arquitectura de una estructura de entidad de ejemplo tal como se contempla en la presente invención. La figura 2, ilustra un esquema de relación de ejemplo. La figura 3, ilustra un esquema de Modelo de Datos de Entidad (EDM). La figura 4, ilustra un mapeo entre y un esquema de entidad (izquierda) y un esquema de base de datos (derecha). La figura 5, ilustra un mapeo representado en términos de solicitudes en un esquema de entidad y un esquema de relación. La figura 6, ilustra vistas bi-direccionales- las vistas de solicitud y actualización -generadas a través del compilador de mapeo a través del compilador de mapeo para el mapeo en la figura 5. La figura 7, ilustra un proceso para apalancar algoritmos de mantenimiento y vista materializados para propagar actualizaciones a través de vistas bi-direccionales. La figura 8, ilustra una inferíase del usuario del diseñador de mapeo. La figura 9, ilustra compilación de un mapeo especificado en un Lenguaje de Especificación de Mapeo (MSL) para generar Vistas de Solicitud y Actualización. La figura 10, ilustra un procesamiento de actualización. La figura 11, ilustra partes lógicas de ejemplo de un mapeador de Relación de Objeto (OR). La figura 12, ilustra la generación de una Vista de Solicitud de Actualización a través de la Plataforma de Datos de Entidad (EDP) cuando se procesa un mapeo especificado en una especificación MSL. La figura 13, ilustra el uso de una QMView en una traducción de solicitud. La figura 14, ilustra el uso de una UMView en una traducción de solicitud. La figura 15, ilustra el manejo de compilación-tiempo y tiempo de corrida de las vistas de mapeo. La figura 16, ilustra la interacción de varios componentes en un proceso de compilación de vista. La figura 17, ilustra una Arquitectura de Traductor de Solicitud EDP (EQT). El EQT utiliza metadatos de mapeo para traducir solicitudes de espacio de objeto/EDM en el espacio de la base de datos. La figura 18, ¡lustra la composición de una variedad de expresiones delta para obtener una expresión delta para tablas en términos de expresiones delta para objetos. Descripción Detallada de la Invención Arquitectura de Acceso de Datos Novedoso En una modalidad, la innovación puede ser implementada dentro e incorpora aspectos de una arquitectura de acceso de dato novedosa - una "Estructura de Entidad" - tal como se describe en esta sección. Un ejemplo de dicha Estructura de Entidad es la arquitectura de acceso de datos ADO.NET vNEXT ® desarrollada por MICROSOFT® Corporation. Lo siguiente es una descripción general de la arquitectura de acceso de datos ADO.NET vNEXT junto con muchos detalles específicos de la implementación , los cuales pueden no ser considerados necesarios para la práctica de la presente invención. REVISION GENERAL Las aplicaciones de cliente-servidor tradicionales relegan las operaciones de solicitud y persistencia en sus datos para sistemas de base de datos, el sistema de base de datos opera en datos en la forma de filas, en tanto que la aplicación opera en datos en términos de construcciones de lenguajes de programación de mayor nivel (clases, estructura, etc). El desacoplamiento de impedancia en los servicios de manipulación de datos entre la aplicación y la hilera de la base de datos fue problemática incluso en sistemas tradicionales. Con la llegada de arquitecturas orientadas al servicio (SOA), los servidores de aplicación y las aplicaciones de hileras múltiples, la necesidad de servicios de acceso de manipulación de datos que estén bien integrados con los ambientes de programación que puedan operar en cualquier hilera, han incrementado en gran medida. La Estructura de Entidad ADO.NET de Microsoft, es una plataforma de programación contra datos que eleva el nivel de abstracción a partir del nivel de relación al nivel conceptual (entidad), y de esta forma reducen significativamente el desacoplamiento de impedancia para servicio de centro de datos y aplicaciones. Los aspectos de la Estructura de Entidad, la arquitectura del sistema general, y la tecnología subyacente se describen más adelante. INTRODUCCIÓN Las aplicaciones modernas requieren servicios de administración de datos en todas las hileras. Necesitan manejar formas de datos cada vez más pesadas que incluyen no únicamente datos de negocio estructurado (tales como Clientes y Órdenes) sino también contenido semi-estructurado y estructurado tal como correo electrónico, calendarios, archivos y documentos. Estas aplicaciones necesitan integrar datos procedentes de múltiples fuentes de datos, así como recolectar, limpiar, transformar y almacenar estos datos para permitir un proceso de toma de decisiones más ágil. Los desabolladores de estas aplicaciones necesitan herramientas de acceso de datos, programación y desarrollo para incrementar su productividad. Aunque las bases de datos de relación se han vueltote hecho el almacén para la mayor parte de los datos estructurados, existen tendencias de que sea\ un desacoplamiento - el problema de desacoplamiento de impedancia bien conocido - entre el modelo de datos (y capacidades) expuestos por dichas bases de datos, y las capacidades de modelado necesarias que necesitan las aplicaciones. Otros dos factores también juegan un papel importante en el diseño de sistemas de empresas. Primero, la representación de datos para aplicaciones tiende a evolucionar en forma diferente a las bases de datos subyacentes. El segundo, muchos sistemas están compuestos de programas de respaldo de la base de datos disparejas con diferentes grados de capacidad. La lógica de aplicación en la hilera media es responsable de las transformaciones de datos que reconcilian estas diferencias y representan una vista de datos más uniforme. Estas transformaciones de datos se vuelven rápidamente complejas. El ¡mplementarlas, especialmente cuando los datos subyacentes necesitan ser actualizables, es un problema difícil y agrega complejidad a la aplicación. Una parte significativa del desarrolló de aplicación - hasta el 40% el algunos casos - se dedica a escribir una lógica de acceso de datos acostumbrada para operar en estos problemas. Existen los mismos problemas, y no son menos severos en los servicios de datos - céntricos. Los servicios convencionales tales como solicitudes, actualizaciones y transacciones han sido implementados en el nivel de esquema lógico (de relación). Sin embargo, la gran mayoría de los servicios más nuevos, tal como replica y análisis, operan de mejor manera en artefactos asociados normalmente con un modelo de datos conceptual, de mayor nivel. Por ejemplo, una Replica SQL SERVER® inventó una estructura denominada "registro lógico" que representa una forma limitada de la Entidad. En forma similar, los Servicios de Reporte de Servidor SQL construyen reportes en la parte superior de un modelo de datos tipo Entidad denominado lenguaje de modelo de datos semántico (SDML). Cada uno de estos servicios tiene herramientas acostumbradas que definen entidades conceptuales y las mapean debajo de las tablas de relación - por consiguiente una entidad de Cliente necesita ser definida y mapeada una vez por replica, otra vez por construcción de reporte, aún otra vez por otros servicios de análisis y así sucesivamente. Como con las aplicaciones, cada servicio termina normalmente en la construcción de una solución acostumbrada a este problema, y en consecuencia, existe un duplicado de código y la capacidad de operación interna limitada entre estos servicios. Las tecnologías de mapeo de objeto a relación (ORM), tales como HIBERNATE® y ORACLE TOPLINK® son alternativas populares para la lógica de acceso de datos acostumbrados. Los mapeos entre la base de datos y las aplicaciones se expresan en una estructura acostumbrada, o a través de anotaciones de esquema. Estas estructuras acostumbradas pueden parecer similares a un modelo conceptual; sin embargo, las aplicaciones no pueden programar directamente contra este modelo conceptual. Aunque los mapeos proporcionan un grado de independencia entre la base de datos y la aplicación, el problema de manejar múltiples aplicaciones con vista ligeramente diferentes de los mismos datos (por ejemplo, considerar dos aplicaciones que desean ver en diferentes proyecciones de una entidad de Cliente), o de las necesidades de servicios que tienden a ser más dinámicas (técnicas de generación de clase a priori no trabajan bien para servicios de datos, ya que la base de datos subyacente puede evolucionar rápidamente) no se dirigen de manera adecuada a estas soluciones. La Estructura de Entidad ADO.NET es una plataforma de programación contra datos que reduce significativamente el desacoplamiento de impedancia para aplicaciones y servicios de datos - céntricos. Difiere de otros sistemas y soluciones en al menos uno de los siguientes aspectos: 1. La Estructura de Entidad define un modelo de datos conceptual pesado (el Modelo de Datos de Entidad, EDM), y un nuevo lenguaje de manipulación de datos (SQL de Entidad) que opera en casos de este modelo. Igual que SQL, el EDM está basado en el valor, es decir, el EDM define los aspectos estructurales de las entidades y no los comportamientos (o métodos). 2. Este modelo está elaborado en concreto a través de un tiempo de corrida que incluye un procesador de mapeo de un programa personalizado que soporta mapeos bi-direccionales potentes (EDM - Relación) para solicitudes y actualizaciones. 3. Las aflicciones y servicios pueden programar directamente contra la capa conceptual a base de valor, o contra abstracciones de objeto específicas - lenguaje programación que pueden elaborarse en capas sobre la abstracción conceptual/entidad), proporcionando una funcionalidad tipo ORM. Consideramos que una abstracción conceptual EDM a base de valor es una base más flexible para compartir datos entre aplicaciones y servicios de datos -céntricos que objetos. 4. Finalmente, la Estructura de Entidad apalanca las tecnologías de Solicitud Integrada del Lenguaje Nuevo de Microsoft (LINQ) que extienden los lenguajes de programación en forma nativa con expresiones de solicitud para reducir en forma adicional, y para los mismos escenarios eliminar completamente la impedancia de desacoplamiento para aplicaciones. La Estructura de Entidad ADO.NET puede ser incorporada en una estructura más grande tal como la Estructura Microsoft .NET. El resto de esta descripción de la arquitectura de acceso de datos, dentro del contexto de una modalidad de Estructura de Entidad ADO.NET, se organiza como se indica a continuación. La sección de "motivación" proporciona una motivación adicional para la Estructura de Entidad. La sección de "Estructura de Entidad" presenta la Estructura de Entidad y el Modelo de Datos de Entidad. La sección de "Patrones de Programación" describen patrones de programación para la Estructura de Entidad. La sección de "Servicios de Objeto" describe el módulo de Servicios de Objeto. La sección de "Mapeo" se enfoca en el componente de Mapeo de la Estructura de Entidad, en tanto que las secciones de "Procesamiento de Solicitud" y "Procesamiento de Actualización" explica como se manejan las solicitudes y actualizaciones. Los "Metadatos" y "Herramientas" describen el subsistema de metadatos y los componentes de herramientas de la Estructura de Entidad. MOTIVACION Esta sección describe por qué la capa de modulado de datos de mayor nivel se ha vuelto esencial para aplicaciones y servicios de datos céntricos. Niveles de Información en Aplicaciones de Datos Las metodologías de modelado de información dominante actuales para producir diseños de base de datos, factoriza un modelo de información en cuatro niveles principales: Físico, Lógico (relacional), Conceptual y Programación/Presentación. El modelo físico describe como los datos se representan en recursos físicos como una memoria, cable o disco. El vocabulario de concepto es descrito en esta capa incluye formatos de registro, divisiones y grupos de archivos, áreas especiales en la memoria, e índices. El modelo físico normalmente es invisible para la aplicación - cambia al modelo físico sino impacta la lógica de la aplicación, pero puede impactar el desempeño de la aplicación. El modelo de datos lógicos es un modelo de información completo y preciso del dominio de objetivo. El modelo de relación es la representación de elección para la mayoría de los modelos de datos lógicos. El concepto descrito en el nivel de lógica incluye tablas, filas, restricciones primarias clave/extraña-clave y normalización. Aunque la normalización ayuda a lograr la consistencia de datos, una concurrencia incrementada, y un mejor desempeño OLTP, también introduce desafíos significativos para las aplicaciones. Los datos normalizados en el nivel lógico con frecuencia son demasiado fragmentados y la lógica de la aplicación necesita ensamblar filas procedentes de múltiples tablas en entidades de mayor nivel que se asemejen en forma más cercana a los artefactos del domino de aplicación. El modelo conceptual captura las entidades de información central del dominio del problema y sus relaciones. Un modelo conceptual bien conocido es el Modelo de Relación de Entidad introducido por Peter Chen en 1976. UML es un ejemplo más reciente de un modelo conceptual. La mayor parte de las aplicaciones implican una fase de diseño conceptual temprano en el ciclo de vida del desarrolló de la aplicación. Sin embargo, desafortunadamente los diagramas del modelo de datos conceptual, permanecen "contra una pared" que crece en forma separada cada vez más de la realidad de la i m plementación de aplicación con el tiempo. Una meta importante de la Estructura de Entidad es realizar el modelo de datos conceptual (representado por el Modelo de Datos de Entidad descrito en la siguiente sección) como una abstracción de la plataforma de datos concreta, y programable. El modelo de programación/representación describe como las entidades y relaciones del modelo conceptual necesitan ser manifestadas (presentadas) en diferentes formas con base en la tarea que está a la mano. Algunas entidades necesitan ser transformadas en objetos de lenguaje de programación para implementar la lógica de negocios de la aplicación, otras necesitan ser transformadas en corrientes XML para invocaciones de servicio; aún otras necesitan ser transformadas en estructuras en la memoria tal como listas o diccionarios para propósitos de enlace de datos de usuario - inferíase. Naturalmente, no existe un modelo de programación universal o forma de presentación, por lo tanto, las aplicaciones necesitan ser mecanismos flexibles para transformar entidades en varias formas de presentación. La mayoría de las aplicaciones y servicios de datos-céntricos pueden igualmente razonar en términos de conceptos de alto nivel tal como una Orden, no con respecto a las diversas tablas en que una orden puede ser normalizada en un esquema de base de datos relacional. Una orden se puede manifestar por sí misma en el nivel de presentación/programación como una instancia de clase en Visual Basic o C#, encapsulando el estado y lógica asociada con la orden, o como una corriente XML para comunicarse con un servicio web. No existe un modelo de presentación adecuado, sin embargo existe un valor en proporcionar un modelo conceptual concreto, y posteriormente tener la capacidad de utilizar dicho modelo como la base para mapeos flexibles para y provenientes de varios modelos de presentación y otros servicios de datos de mayor nivel. Evolución de Aplicaciones y Servicios Las aplicaciones a base de datos de hace 10 ó 20 años, eran estructuradas normalmente como monolitos de datos; los sistemas cerrados con lógica se factorizaron con funciones de verbo-objeto (por ejemplo, crear - orden, actualizar - cliente) que interactuaron con un sistema de base de datos en el nivel del esquema de lógica. Varias tendencias significativas han elaborado la forma en que las aplicaciones a base de datos modernas son factorizadas y desplegadas actualmente. Principalmente entre éstas se encuentran factorización orientada al objeto, composición de aplicación de nivel de servicio y servicios de datos - céntricos de mayor nivel. Las entidades conceptuales son una parte importante de aplicación de las aplicaciones actuales. Estas entidades deben ser mapeadas a una variedad de representaciones y enlazadas a una variedad de servicios. No existe un enlace de representación o servicio correcto; XML, las representaciones Relaciónales y de Objeto todas son importantes, pero solas no son suficientes para todas las aplicaciones. Por consiguiente, existe la necesidad de una estructura que soporte una capa de modelado de datos de mayor nivel, y también permita que las capas de presentación múltiples sean conectadas la Estructura de Entidad ayuda a cumplir estos requerimientos. Los servicios de datos-céntricos también han evolucionado en una forma similar. Los servicios proporcionados por una "plataforma de datos" 20 años antes, eran mínimos y enfocados alrededor del esquema lógico en un RDBMS. Estos servicios incluían consulta y actualización, transacciones atómicas, y operaciones de volumen, tal como soporta y carga/extracción. El servidor SQL por sí mismo está evolucionando de un RDBMS tradicional a una plataforma de datos completa que proporciona un número de servicios de datos - céntricos de alto nivel con respecto a entidades realizadas en el nivel de esquema conceptual. Diversos de los servicios de dato -céntricos de mayor nivel en el producto del servidor SQL Replica, Constructor de Reporte por nombrar sólo un par de ellos - están proporcionando cada vez sus servicios en el nivel de esquema conceptual. Actualmente, cada uno de estos servicios tiene una herramienta separada para describir entidades conceptuales y mapearlas debajo del nivel de esquema lógico subyacente. La meta de la Estructura de Entidad es proporcionar una abstracción conceptual de mayor nivel, común que todos estos servicios pueden compartir. LA ESTRUCTURA DE ENTIDAD La Estructura ADO.NET de Microsoft's que existió antes de la Estructura de Entidad aquí descrita, fue una tecnología de acceso de datos que permitió que las aplicaciones fueran conectadas a almacenes de datos y manipularan datos contenidos en ellos en varias formas. Fue parte de la Estructura .NET de Microsoft, y estuvo integrada en gran medida con el resto de la biblioteca de clase Estructura .NET. La estructura ADO.NET anterior tenía dos partes principales: proveedores y servicios. Los proveedores ADO.NET son los componentes que conocen cómo hablar en almacenes de datos específicos. Los proveedores están compuestos de tres piezas centrales de funcionalidad: acceso de manejo de conexiones a la fuente de datos subyacente; comandos representan un comando (solicitud, llamada de procedimiento, etc) que será ejecutado contra la fuente de datos; y vectores de datos que representan el resultado de la ejecución del comando. Los servicios ADO.NET incluyen componentes de proveedor - neutral tal como DataSet para permitir escenarios de programación de datos fuera de línea. (Un DataSet es una representación que reside en la memoria de datos que proporciona un modelo de programación relacional consistente sin importar la fuente de datos).

Estructura de Entidad - Revisión General La Estructura de Entidad ADO.NET se construye en el modelo de proveedor ADO.NET pre-existente, y agrega la siguiente funcionalidad: 1. Un modelo de datos conceptual nuevo, el Modelo de Datos de Entidad (EDM), para ayudar a esquemas conceptuales de modelo. 2. Un Nuevo lenguaje de manipulación de datos (DML), Entidad SQL, para manipular instancias del EDM, y una representación programática de una consulta (árboles de comando canónicos) que se comunican con diferentes proveedores. 3. La capacidad de definir mapeos entre el esquema conceptual y los esquemas lógicos. 4. Un proveedor ADO.NET que programa el modelo contra el esquema conceptual. 5. Una capa de servicios de objeto que proporciona funcionalidad tipo ORM. 6. Integración con tecnología LINQ para ser fácil programar contra datos en la forma de objetos procedentes de lenguajes . NET. El Modelo de Datos de Entidad El Modelo de Datos de Entidad (EDM) permite el desarrolló de aplicaciones de datos - céntricos pesados. Extiende el modelo relacional clásico con conceptos del dominio E-R. En la modalidad de ejemplo aquí proporcionada, los conceptos de organización en el EDM incluyen entidades y relaciones. Las Entidades representan partidas de alto nivel con identidad, en tanto que las Relaciones se utilizan para relacionar (o, describir relaciones) dos o más entidades. En una modalidad, el EDM se basa en un valor tipo el modelo relacional (y SQL), en lugar de a base de objeto/referencia tipo C# (CLR). Varios modelos de programación de objetos pueden elaborarse en capas fácilmente en la parte superior del EDM. En forma similar, el EDM puede mapearse a una o más implementaciones DBMS para persistencia. El EDM y la Entidad SQL representa un modelo de datos más pesado y un lenguaje de manipulación de datos para una plataforma de datos y pretender permitir aplicaciones tales como CRM y ERP, servicios de datos - intensivos tales como Reporte, Inteligencia de Negocios, Replica y Sincronización, y aplicaciones de datos - intensivos para modelar y manipular datos en un nivel de estructuras semánticas que es más cercana a sus necesidades. Nosotros describimos varios conceptos que pertenecen al EDM. Tipos EDM Una EntityType describe la estructura de una entidad. Una entidad puede tener cero o más propiedades (atributos, campos) que describen la estructura de la entidad. Además, un tipo de entidad debe definir una clave- un grupo de propiedades cuyos valores se identifican de manera única la instancia de entidad dentro de una recolección de entidades. Un EntityType se puede derivar de (o subtipo) otro tipo de entidad - el EDM soporta un modelo heredado simple. Las propiedades de una entidad pueden ser tipos simples o complejos. Un SimpleType representa tipos escalares (o atómicos) (por ejemplo, entero, cadena) en tanto que un ComplexType representa propiedades estructuradas (por ejemplo una Dirección). Un ComplexType está compuesto de cero o más propiedades tipo escalar o complejas. Un RelationshipType describe relaciones entre dos (o más) tipos de entidad. Los Sistemas EDM proporcionan un mecanismo de agrupación para tipos - tipos deben ser definidos en un esquema. El espacio de nombre del esquema combinado con el nombre de tipo identifica únicamente el tipo específico. Modelo de Instancia EDM Las instancias de entidad (o sólo entidades) están contenidas en forma lógica dentro de un EntitySet. Un EntitySet es una recolección homogénea de entidades, es decir, todas las entidades en un EntitySet deben ser las mismas (o derivadas) EntityType. Un EntitySet es similar en forma conceptual a una tabla de base de datos, en tanto que una entidad es similar a una fila de una tabla. Una instancia de entidad debe pertenecer exactamente a un grupo de entidad. En una forma similar, las instancias de relación están contenidas lógicamente dentro de un RelationshipSet. La definición de un RelationshipSet alcanza la relación. Esto es, identifica los EntitySets que mantienen instancias de los tipos de entidad que participan en la relación. Un RelationshipSet es conceptualmente similar a un enlace -tabla en una base de datos. Los StmpleTypes y ComplexTypes únicamente pueden ser ejemplicados como propiedades -EntityType. Un EntityContainer es una agrupación lógica de EntitySets y RelationshipSets - en forma similar a como un Esquema es un mecanismo de agrupamiento para tipos EDM. Un Esquema EDM de Ejemplo A continuación se muestra, un esquema EDM de ejemplo: <?xml versión-"!.0" encoding="utf-8"?> <Schema Namespace="AdventureWorks" Alias-'Self ...> <EntityContainer Name="AdventureWorksContainer"> <EntitySet Name="ESalesOrders" Ent¡tyType="Self . ESalesOrder" / > <EntitySet Name= " ESalesPersons" EntityType-'Self . ESalesPerson"/> AssociationSet Name- 'ESales PersonOrders" Association- 'Self . ESalesPersonOrder" > <End Role="ESalesPerson" EntitySet- 'ESalesPersons" / > <End Role= "EOrder"EntitySet="ESalesOrders" / > </AssociationSet> </EntityContainer> < ! -- Sales Order Type Hierarchy -- > <EntityType Name="ESalesOrder"Key=" ld"> <Property Name=" Id" Type= "Int32" Nullable="false" / > <Property Name="AccountNum" Type="String" MaxLength="15" / > </EntityType> <EntityType Name="EStoreSalesOrder" BaseType="Self.ESalesOrder" > <Property Name="Tax" Type = "Decimal" Precision="28" Scale = "4" / > </EntityType> <! — Person EntityType — > <EntityType Ñame ="ESalesPerson" Key = "Id" > <! - Properties from ESalesPersons table -> <Property Name="ld" Type ="lnt32" Nullable- 'false" / > <Property Name="Bonus" Type =" Decimal" Precision="28" Scale ="4" / > <! - Properties from SEmployees table --> <Property Name- 'Title" Type = "String" MaxLength="50" / > <Property Name="HireDate" Type = "DateTime'7 > < ! -- Properties from the SContacts table -- > <Property Name="Name" Type = "String" MaxLength ="50" / > <Property Name="Contact" Type = "Self.Contactlnfo" Nullable-'false" / > </EntityType> <ComplexType Name="Contactlnfo"> <Property Name="Email"Type="String" MaxLength="50" / > <Property Name="Phone" Type = "String" MaxLength = "25" / > </ComplexType> <Association Name="ESalesPersonOrder"> <End Role="EOrder" Type = "Self.ESalesOrder" Multiplicity="*7 > <End Role="ESalesPerson" Multiplicity = "1" Type="Self .ESalesPerson" / > </Association> </Schema> Arquitectura de Alto Nivel Esta sección señala la arquitectura de la Estructura de Entidad ADO.NET. Sus componentes funcionales principales se ilustran en la figura 1, y comprenden lo siguiente: Proveedores de fuentes de datos - específicos. La Estructura de Entidad 100 se construye en el modelo de proveedor de datos ADO.NET. Existen proveedores específicos 122-125 para diversas fuentes de datos tales como Servidor SQL 151, 152, fuentes relaciónales 153, no relaciónales 154, y fuentes de servicios Web 155. Los proveedores 122-125 pueden ser llamados de un Proveedor ADO.NET API 121 específico el almacén.

Proveedor EntityClient. El proveedor EntityClient 110 representa una capa de programación conceptual concreta. Es un proveedor de datos a base de valor, nuevos en cuando los datos son accesados en términos de entidades EDM y relaciones y es consultado/actualizado utilizando un lenguaje SQL a base de entidad (SQL de Entidad). El proveedor EntityClient 111 forma un paquete de Servicios de Datos de Entidad 110 que también puede incluir servicios de metadatos 112, trayecto de solicitud y actualización 113, soporte de transacciones 115, un tiempo de corrida del administrador de vista 116, y un subsistema de mapeo de vista 114 que soporta vistas EDM actualizables en tablas relaciónales planas. El mapeo entre planas de entidades es declarativamente específico a través de un lenguaje de especificación de mapeo. Servicios de Objeto y otras Capas de Programación. El componente de Servicios de Objeto componente 131 de la Estructura de Entidad 100 proporciona una abstracción de objetos pesada en las entidades, un conjunto de servicios pesados sobre estos objetos, y permite que las aplicaciones se programen en una experiencia de codificación imperativa 161 utilizando construcciones de lenguaje de programación familiares. Este componente proporciona servicios de administración de estado para objetos (incluyendo rastreo de cambio, resolución de identidad), soporta servicios para objetos y relaciones de navegación y carga, soporta solicitudes a través de LINQ y SQL de Entidad utilizando componentes tales como Xlinq 132, y permite que los sujetos sean actualizados y persistidos. La Estructura de Entidad permite que varias capas de programación parecidas a 130, sean conectadas en la capa de servicios de datos de entidad a base de valor 110 expuestas por el proveedor EntityClient 111. El componente de Servicio de Objetos 131 es una de dichas capas de programación que aparecen en los objetos CLR y proporciona funcionalidad tipo ORM. El componente de los servicios de Metadatos 112 administra los metadatos para las necesidades de tiempo de diseño y tiempo de corrida de la Estructura de Entidad 100, y las aplicaciones en la Estructura de Entidad. Todos los metadatos asociados con lo conceptos EDM (entidades, relaciones, EntitySets, RelationshipSets), almacenan conceptos (tablas, columnas, restricciones) y mapean conceptos que están expuestos a través de interfases de metadatos. El componente de metadatos 112 también sirve como un enlace entre las herramientas de modelado de dominio que soportan el diseño de aplicación de conducción - modelo. Herramientas de Diseño y Metadatos. La Estructura de Entidad 100 se integra con los diseñadores de dominio 170 para permitir el desarrollo de la aplicación conducida pro el modelo. Las herramientas incluyen herramientas de diseño EDM, herramientas de modelado 171, herramientas de diseño de mapeo 172, herramientas de diseño de buscador 173, herramientas de diseño de enlace 174, herramientas de generación de código 175, y modeladores de solicitud. Servicios. Los servicios de datos - céntricos pesados tales como Reportes 141, Sincronización 142, Servicios Web 143 y Análisis de Negocios pueden construirse utilizando la Estructura de Entidad 100. PATRONES DE PROGRAMACIÓN La Estructura de Entidad ADO.NET junto con LINQ incrementa la productividad del desarrollador de aplicación, reduciendo en forma significativa el desacoplamiento de impedancia entre códigos y datos de aplicación. En esta sección, describimos la evolución en los patrones de programación de acceso de datos en las capas de abstracción lógicas, conceptuales y de objetos. Se debe considerar el siguiente fragmento de esquema relacional con base en la base de datos Adventure Works de muestra. Esta base de datos consiste en tablas SContacts 201, SEmployees 202, SSalesPersons 203, y SSalesOrders 204, las cuales pueden seguir un esquema relacional tal como se ilustra en la figura 2. SContacts (Contactld, Ñame, Email, Phone) SEmployees (Employeeld, Title, HireDate) SSalesPersons (SalesPersonld, Bonus) SSalesOrders (SalesOrderld, SalesPersonld) Considerar un fragmento de código de aplicación para obtener el nombre y fecha de contrato de las personas de ventas, quienes son contratados antes de cierta fecha (ver más adelante). Existen cuatro inconvenientes principales en este fragmento de código que tienen poco que hacer con la pregunta del negocio que tiene que ser resuelta. Primero, incluso aunque la solicitud pueda ser manifestada en idioma Inglés en forma muy fácil, la expresión SQL es muy verbal y requiere que el desarrollador esté atento del esquema relacional normalizado para formular la unión de multi-tabla requerida para recolectar las columnas adecuadas de las tablas SContacts, SEmployees, y SSalesPerson. Además, cualquier cambio a los esquemas de la base de dato subyacente requerirán cambios correspondientes en el fragmento de código que se encuentra más adelante. Segundo, el usuario tiene que definir una conexión explícita para la fuente de datos. Tercero, ya que los resultados regresados no están fuertemente tecleados, cualquier referencia a nombres de columnas no existentes serán captadas únicamente después de que se haya ejecutado la solicitud. Cuarto, la expresión SQL es una propiedad de cadena para el Comando API y cualesquiera errores en su formulación serán únicamente captados en el tiempo de ejecución. Aunque este código se escribe utilizando ADO.NET 2.0, el patrón de código y sus convenientes aplica cualquier otro acceso de datos relacional API tal como ODBC, JDBC, o OLE-DB. evitar EmpsByDate (DateTime date) { utilizando ( SqlConnection con = nuevo SqlConnection (CONN_STRING) ) { con.Open ( ) ; SqlCommand cmd = con . CreateCommand ( ); cmd . CommandText = @" SELECT SalesPersonID, FirstName, HireDate FROM SSalesPersons sp INNER JOIN SEmployees e ON sp. SalesPersonID = e.EmployeeID INNER JOIN SContacts c ON e.EmployeeID = c. ContactID WHERE e. HireDate < ©date"; cmd. Parameters .AddWithValue ( "@date",date) ; DbDataReader r = cmd.ExecuteReadeir ( ); en tanto (r.Read( )) { • Console.WriteLine (" {0:d}: \ t {1} " r["HireDate"] , r ["FirstName"] ) ; }}} El esquema relacional de muestra puede ser capturado en el nivel conceptual a través de un esquema EDM, tal como se ilustra en la figura 3. Define un tipo de entidad ESalesPerson 302 que abstrae la fragmentación de las tablas SContacts 201, SEmployees 202, y SSalesPersons 203. También captura la relación heredada entre los tipos de entidad EStoreOrder301 y ESalesOrder 303. El programa equivalente en la capa conceptual se describe como se indica a continuación: evitar EmpsByDate (DateTime date) { utilizando ( EntityConnection con = nuevo EntityConnection (CONN_STRING) ) { con . Open ( ) ; EntityCommand cmd = con .CreateCommand ( ); cmd.CommandText = @" SELECT VALUE sp FROM ESalesPersons sp WHERE sp.HireDate < @date"; cmd . Parameters . AddWithValue { "date", date); DbDataReader r = cmd.ExecuteReader ( CommandBehavior . SequentialAccess); en tanto (r. Read () { Consolé . WriteLine (" {0:d}: \ t {1}" , if'HireDate"] ] , r [ "FirstName"] ) }}} La expresión SQL ha sido simplificada en forma considerable - el usuario ya no tiene que saber anda con respecto a la distribución precisa de la base de datos. Además, la lógica de la aplicación puede ser aislada de cambios al esquema de la base de datos subyacente. Sin embargo, este fragmento aún está basado en una cadena, aún no obtiene los beneficios de programar la revisión tipo lenguaje, y regresa resultados tecleados en forma débil. Al agregar una envoltura de objeto delgada alrededor de entidades y utilizar las extensiones de Solicitud Integrada de Lenguaje (LINQ) en C#, se puede rescribir la función equivalente sin desacoplamiento de impedancia como se indica a continuación: evitar EmpsByDate (DateTime date) { utilizar (AdventureWorksDB aw = nuevo AdventureWorksDB ()) { var people = from p in aw . Salespersons where p.HireDate < date select p; para cada uno (Salesperson p in people) { Consolé . WriteLine ( " { 0:d} \t {1}" , p.HireDate, p . FirstName) ; }}} La solicitud es simple; la aplicación se aisla (en gran medida) de cambios al esquema de base de datos subyacente, y la solicitud es tipo - revisada completamente por el compilador C#. Además, de las solicitudes, se puede interactuar con objetos y llevar a cabo operaciones de Crea, Leer y Actualizar y Eliminar (CRUD) regulares en los objetos. Los ejemplos de éstas se describen en la sección de Procesamiento de Actualización . SERVICIOS DE OBJETO El componente de Servicios de Objeto es una capa de programación/presentación sobre la capa conceptual (entidad). Aloja varios componentes que facilitan la interacción entre el lenguaje de programación y las entidades de la capa conceptual a base de valor. Esperamos que exista un servicio de objetos por programación de tiempo de corrida de lenguaje (por ejemplo .NET, Java). Si se diseña para soportar los programas .NET CLR, en cualquier lenguaje .NET, puede interactuar con la Estructura de Entidad. Los Servicios de Objeto están compuestos de los siguientes componentes principales: La clase ObjectContext aloja la conexión de la base de datos, espacio de trabajo de metadatos, administrador de estado de objeto y materializador de objeto. Esta clase incluye una interfase de solicitud de objeto de objeto ObjectQuery<Y> que permite la formulación de solicitudes en cualquiera de la sintaxis SQL de Entidad o LINQ, y regresa resultados de objeto fuertemente tecleados como un ObjectReader<T> . El ObjectContext también expone interfases de nivel - objeto de solicitud y actualización (por ejemplo SaveChanges) entre la capa de lenguaje de programación y la capa conceptual. El administrador de estado de Objeto tiene tres funciones principales: (a) resultados de solicitud caché, proporcionar resolución de identidad y manejar políticas para que surjan objetos de los resultados de solicitud de traslape, (b) rastreo de cambios en memoria, y (c) construir la entrada de la lista de cambio a la infraestructura de procesamiento de actualización. El administrador de estado de objeto mantiene el estado de cada entidad en la caché - separada (de la caché), agregada, no cambiada modificada y eliminada - y rastrea sus transiciones de estado. El materializador de Objeto llevó a cabo las transformaciones durante la solicitud de actualización entre valores de entidad de la capa conceptual y los objetos CLR correspondientes.

MAPEO En una modalidad, el esqueleto de la capa de acceso de datos de propósitos generales, tal como la Estructura de Entidad ADO.NET, puede ser un mapeo que establece una relación entre los datos de aplicación y los datos almacenados en la base de datos. Una aplicación solicita y actualiza datos en el nivel de objeto o conceptual y estas operaciones son trasladadas al almacén a través del mapeo. Existe un número de desafíos técnicos que tienen que ser atendidos por cualquier solución de mapeo. Es relativamente sencillo construir un ORM que utilice un mapeo uno - a - uno que exponga cada fila en una tabla relacional como un objeto, especialmente si no se requiere una manipulación de datos de declaración. Sin embargo, ya que los mapeos son más complejos, las operaciones a base de conjuntos, desempeño, soporte de proveedor múlti-DBMS, y otros requerimientos de pesado, cada vez están menos al alcance de sus soluciones ad hoc. Problema: Actualizaciones mediante Mapeos El problema de accesar datos mediante mapeos puede ser modelados en términos de "vistas", es decir, los objetos/entidades en la capa del cliente pueden ser considerados como vistas pesadas sobre las filas de las tablas. Sin embargo, es bien sabido que únicamente una clase de vistas limitada es actualizable, por ejemplo, los sistemas de base de datos comerciales no permiten actualizaciones a múltiples tablas en vistas que contienen uniones o articulaciones. Encontrar una traducción de actualización única en vista incluso muy simples, es raramente posible debido a la sub-especificación intrínseca del comportamiento de la actualización por parte de una vista. La investigación ha mostrado que el incitar las semánticas de actualización de las vistas es difícil y puede requerir una experiencia significativa por parte del usuario. Sin embargo, para acceso de datos conducidos por el mapeo, es conveniente que exista una traducción bien definida de cada actualización para la vista. Además, en escenarios conducidos por mapeo, el requerimiento de capacidad de actualización va más allá de una vista simple. Por ejemplo, una aplicación de negocios que manipula las entidades de Cliente y Orden lleva a cabo en forma efectiva operaciones contra dos vistas. Algunas veces se puede lograr únicamente un estado de aplicación consistente, actualizando varias vistas en forma simultánea. La traducción caso por caso de dichas actualizaciones puede producir una explosión de combinación de la lógica de actualización. El delegar su implementación a los desabolladores de la aplicación, no es satisfactorio debido a que requiere que afronten en forma manual una de las partes más complicadas del acceso de datos. El Método de Mapeo ADO.NET La Estructura de Entidad ADO.NET soporta una arquitectura de mapeo innovadora que aspira dirigirse a los desafíos anteriores. Explota las siguientes ideas: 1. Especificación: los mapeos son especificados utilizando un lenguaje de declaración que tiene semánticas bien definidas y coloca un amplio rango de escenarios de mapeo dentro del alcance de usuarios no expertos. 2. Compilación: los mapeos con compilados en vistas bi-direccionales , denominadas vistas de solicitud y actualización, que conducen el procesamiento de solicitud y actualización en el procesador de tiempo de corrida. Ejecución: traducción de Actualización se realiza utilizando un mecanismo general que apalanca el mantenimiento de vista materializado, una tecnología de base de datos robusta. La traducción de la Solicitud utiliza un desdoblamiento de vista. La arquitectura de mapeo nueva permite construir una pila poderosa de tecnologías conducidas por el mapeo en una forma futurista, con principios. Además, abre direcciones de investigación interesantes de relevancia práctica inmediata. Las siguientes sub-secciones, ilustran la especificación y compilación de mapeos. La ejecución se considera en las secciones de Procesamiento de Solicitud y Procesamiento de Actualización, que se encuentran más adelante. Aspectos y modalidades adicionales de una arquitectura de mapeo de ejemplo tal como aquí se proporciona, también se establecen en la sección que se encuentra más adelante titulada "Aspectos y Modalidades Adicionales". Especificación de Mapeos Se especifica un mapeo utilizando un grupo de fragmentos de mapeo. Cada fragmento de mapeo es una restricción de la forma QEntmes = QTabies en cuando QEntities es una solicitud en el esquema de entidad (en el lado de la aplicación) y Qiabies es una solicitud sobre el esquema de la base de datos (en la parte del almacén). Un fragmento de mapeo describe, una parte de los datos de entidad corresponden a una parte de los datos de relación. Eso es, un fragmento de mapeo es una unidad elemental de especificación que puede ser comprendida en forma independiente de otros fragmentos. Para ilustración, se debe considerar el escenario de mapeo de muestra de la figura 4. La figura 4 muestra un mapeo entre y el esquema de entidad (izquierda) y un esquema de base de datos (derecha). El mapeo puede ser definido utilizando un archivo XML o una herramienta gráfica. El esquema de entidad corresponde a uno en la sección de Modelo de Datos de Entidad de la presente invención. En la parte del almacén existen cuatro tablas, SSalesOrders, SSalesPersons, SEmployees, y SContacts. En la parte del esquema de entidad existen dos conjuntos de entidad, ESalesOrder y ESalesPersons, y un conjunto de asociación, ESalesPersonOrders.

El mapeo se representa en términos de solicitudes en el esquema de entidad y el esquema relacional como se muestra en la figura 5. En la figura 5, el Fragmento 1 es el conjunto de valores (Id, AccountNum) de todas las entidades del tipo exacto ESalesOrder en ESalesOrders es idéntico al conjunto de valores (SalesOrderld , AccountNum) recuperados de la tabla SSalesOrders para lo cual es cierto IsOnline. El Fragmento 2 es similar. El Fragmento 3 mapea el conjunto de asociación de ka tabla ESalesPersonOrders a la tabla SSalesOrders y se dice que cada entrada de asociación corresponde al par de clave primaria, clave extraña para cada fila en esta tabla. Los Fragmentos 4, 5, y 6 se dice que son entidades en el conjunto de entidad ESalesPersons que se dividen a través de las tres tablas SSalesPersons, SContacts, SEmployees. Vistas Bi-direccionales Los mapeos son compilados en vistas SQL de Entidad bi-direccional que conducen el tiempo de corrida. Las vistas de solicitud expresan entidades en términos de tablas, en tanto que las vistas de actualización expresan tablas en términos de entidades. Las vistas de actualización pueden ser un tanto contra intuitivas debido a que especifican datos persistentes en términos de constructores virtuales, pero tal como mostraremos más adelante, pueden ser apalancadas para soportar actualizaciones en una forma elegante. Las vistas generadas "respetan" el mapeo en un sentido bien definido y tienen las siguientes propiedades (se debe observar que la presentación está simplificada ligeramente - en particular, de estado persistente no está determinado completamente por el estado virtual): Entidades = QueryViews(Tablas) Tablas = UpdateViews(Entidades) Entidades = QueryViews(UpdateViews(Entidades)) La última condición es el criterio de transacción circular, el cual asegura que todos los datos de entidad pueden ser persistidos y re-organizados en la base de datos en una forma no suelta. El compilador de mapeo incluido en la Estructura de Entidad, garantiza que las vistas generadas satisfagan el criterio de transacción circular. Surge un error si no se pueden producir dichas vistas a partir del mapeo de entrada. La figura 6, muestra las vistas bi-direccionales - las vistas de solicitud y actualización - generadas por el compilador de mapeo para el mapeo en la figura 5. En general, las vistas pueden ser significativamente más complejas que el mapeo de entrada, ya que especifican en forma explícita las transformaciones de datos requeridas. Por ejemplo, en QVi, el conjunto de entidad ESalesOrders se construye a partir de la tabla SSalesOrders, de modo que ya sea un ESalesOrder o un EStoreSalesOrder es ejemplificado dependiendo de si la señal IsOnline es cierta o no. para reorganizar el conjunto de entidad ESalesPersons de las tablas relaciónales, se necesita llevar a cabo una unión entre las tablas SSalesPersons. SEmployees, y SContacts tables (QV3). El escribir la lista de solicitud y actualización a mano de modo que se satisfaga el criterio de transacción circular, es delicado y requiere una experiencia significativa con bases de datos; por consiguiente, las modalidades de la presente invención de la Estructura de Entidad únicamente aceptan las vistas producidas por el compilador de mapeo incorporado, aunque el aceptar vistas producidas por otros compiladores o manuales es ciertamente verosímil en modalidades alternativas. Compilador de Mapeo La Estructura de Entidad contiene un compilador de mapeo que genera las vistas de solicitud y actualización del esquema EDM, el esquema de almacén y el mapeo (los artefactos de metadatos se describen en la sección de Metadatos de la presente invención). Estas vistas son consumidas por los trayectos de solicitud y consulta. El compilador puede ser invocado ya sea en el tiempo de diseño o tiempo de corrida cuando se ejecuta la primera solicitud contra el esquema EDM. Los algoritmos de generación de vista utilizados en el compilador están basados en técnicas de contestación - solicitud - utilización - vistas para reescrituras exactas.

Procesamiento de Solicitud Lenguajes de Solicitud En una modalidad, la Estructura de Entidad puede ser diseñada para trabajar con múltiples lenguajes de solicitud. Describimos las modalidades de SQL y LINQ de Entidad con más detalle en la presente invención, quedando entendido que se pueden extender a otras modalidades los mismos principios o principios similares. SQL de Entidad SQL de Entidad es un derivado de SQL diseñado para solicitar y manipular instancias EDM. El SQL de Entidad extiende SQL estándar en las siguientes formas. 1. Soporte Nativo para construcciones EDM (entidades, relaciones, tipos complejos, etc): constructores, accesores de miembros, interrogación de tipo, navegación de relación, nido/sin nido, etc. 2. Espacios de nombre. SQL de Entidad utiliza espacios de nombres como una construcción de agrupamiento para tipos y funciones (similar a XQuery y otros lenguajes de programación). 3. Funciones extensibles. SQL de Entidad soporta funciones no incorporadas. Todas las funciones (min, max, subcadena, etc.) son definidas extrañamente en un espacio de nombre, y son importadas en una solicitud, normalmente del almacén subyacente. 4. Un tratamiento más ortogonal de la sub-consulta y otras construcciones en comparación con SQL. La Estructura de Entidad, puede por ejemplo, soportar el SQL de Entidad como el lenguaje de solicitud en al capa del proveedor EntityClient, y en el componente de Servicio de Objeto. Se muestra una solicitud SQL de Entidad de muestra, en la sección de Patrones de Programación de la presente invención. Solicitud Integrada por Lenguaje (LTNQ) La solicitud integrada por lenguaje, o LINQ, es una innovación en los lenguajes de programación .NET que introducen construcciones relacionadas con la solicitud para estandarizar lenguajes de programación tales como C# y Visual Basic. Las expresiones de solicitud no son procesadas por una herramienta extraña o pre-procesador de lenguaje, sino más bien son expresiones de primera clase de los propios lenguajes. LINQ permite que las expresiones de solicitud se beneficien de los metadatos pesados, revisiones, sintaxis de tiempo -compilación, tecleado estático y IntelHSense que fueron disponibles previamente únicamente para el código imperativo. LINQ define un conjunto de operadores de solicitud estándar de propósitos generales que permiten operaciones transversales, de filtro, de unión, de proyección, de clasificación y agrupamiento para que sean expresadas en una forma directa, aún declarativa en cualquier lenguaje de programación a base de .NET-. Los lenguajes .NET tales como Visual Basic y C# también soportan comprensiones de solicitud - extensiones de sintaxis de lenguaje que apalancan a los operadores de solicitud estándar. Una solicitud de ejemplo que utiliza LINQ en C#, se muestra en la sección de Patrones de Programación de la presente invención. Árboles de Comando Canónicos En una modalidad, los Árboles de Comando Canónicos -más simplemente, árboles de comando - que pueden ser la representación programática (árbol) de todas las solicitudes en una Estructura de Entidad. Las solicitudes expresadas a través de SQL o LINQ de Entidad pueden ser analizadas primero y convertidas en árboles de comando; todos los procesamientos subsecuentes pueden llevarse a cabo en los árboles de comando. La Estructura de Entidad también puede permitir que las solicitudes sean construidas en forma dinámica (o editadas) mediante la construcción/edición del árbol de comando APIs. Los árboles de comando pueden representar solicitudes en ciertas actualizaciones, eliminaciones y llamadas del procedimiento. Un árbol de comando está compuesto de una o más Expresiones. Una Expresión representa simplemente algún cómputo - la Estructura de Entidad puede proporcionar una variedad de expresiones incluyendo constantes, parámetros, operaciones aritméticas, operaciones relaciónales (proyección, filtración, unión, etc), llamadas de función, etc. Finalmente, los árboles de comando se pueden utilizar como el medio de comunicación para solicitudes entre el proveedor EntityClient y el proveedor específico - almacén subyacente. Trayecto de Solicitud La ejecución de la solicitud de una modalidad de la Estructura de Entidad puede delegarse a los almacenes de datos. La infraestructura del procesamiento de solicitud de la Estructura de Entidad es responsable de romper una solicitud de SQL o LINQ de Entidad de una o más solicitudes elementales, únicamente relaciónales que pueden ser evaluadas a través del almacén subyacente, junto con información de ensamble adicional, la cual se utiliza para reformar los resultados planos de las Solicitudes más sencillas que se encuentran en las estructuras EDM más pesadas. La Estructura de Entidad puede asumir, por ejemplo, que debe almacenar capacidades de soporte y similares a las del Servidor SQL 2000. Las solicitudes pueden fragmentarse en solicitudes relaciónales - planas más simples que se ajustan a este perfil. Otras modalidades de una Estructura de entidad puede permitir que los almacenes tomen mayores partes del procesamiento de solicitud. Una solicitud típica puede ser procesada como se indica a continuación. Análisis de sintaxis y Semántica . Una solicitud SQL de Entidad se analiza primero y se analiza en forma semántica utilizando información del componente de servicios de Metadatos. Las solicitudes LINQ son analizadas como parte el compilador de lenguaje adecuado. Conversión a un Árbol de Comando Canónico. La solicitud ahora se convierte en un árbol de comando, sin importar como se expresó originalmente, y como se validó. Desdoblamiento de Vista de Mapeo. Las solicitudes en la Estructura de Entidad se dirigen a los esquemas conceptuales (EDM). Estas solicitudes deben ser traducidas para hacer referencia más bien a las tablas y vistas de las bases de datos subyacentes. Este proceso - referido como desdoblamiento de vista de mapeo - es análogo al mecanismo de desdoblamiento de vista en sistemas de bases de datos. El mapeo entre el esquema EDM y el esquema de base de datos se compilan en vistas de solicitud y actualización. La vista de solicitud posteriormente es desdoblada en la solicitud del usuario - ahora la solicitud se dirige a las tablas y vistas de la base de datos. Eliminación de tipo Estructurado . Todas las referencias a tipos estructurados sólo son eliminados de la solicitud, y agregadas a la información de re-organización (para guía de ensamble de resultado). Eso incluye referencias a constructores de tipo, accesores de miembros, expresiones de interrogación de tipo. Recorte de Proyección . La solicitud es analizada, y las expresiones no referenciadas en la solicitud son eliminadas. Detención de Nido. Cualesquiera operaciones se anida mediante (construcción de colecciones anidadas) en la solicitud, son empujadas a la raíz del árbol de solicitud a través de un sub-árbol que contiene únicamente operadores relaciónales. Normalmente, la operación de anidamiento es transformada en una unión extraña izquierda (o una aplicación extraña) y los resultados planos de la solicitud resultante posteriormente son re-organizados (ver la sección de ensamble de los resultados que se encuentran más adelante) en los resultados adecuados. Transformaciones. Un conjunto de transformaciones heurísticas se aplican para simplificar la solicitud. Estas incluyen caídas de filtro, aplicar a conversiones de unión, desdoblamiento de expresión de casos, etc. Las uniones redundantes (auto-uniones, clave primaria, uniones de clave extraña) son eliminadas en esta etapa. Se debe observar que la infraestructura de procesamiento de solicitud de la presente invención no lleva a cabo una optimización a base de costo. Traducción en Comandos Específicos de un Proveedor. La solicitud (es decir árbol de comando) ahora es manejada por proveedores para producir un comando específico - proveedor, posiblemente en el dialecto SQL nativo de los proveedores. Nos referimos a este paso como SQLGen. Ejecución . Se ejecutan comandos del proveedor Ensamble de Resultados. Los resultados (Data Readers) de los proveedores se reforman posteriormente en la forma adecuada utilizando la información de ensamble reunida anteriormente, y se regresa a quién lo invoca un DataReader simple. Materialización . Para solicitudes presentadas a través del componente de Servicios de Objeto, los resultados son materializados posteriormente en los objetos del lenguaje de programación adecuados. SQLGen Tal como se mencionó la sección anterior, la ejecución de solicitud puede ser delegada al almacén subyacente. En dichas modalidades, una solicitud debe ser traducida primero en una forma que es adecuada para el almacén. Sin embargo, diferentes almacenes soportan diferentes dialectos de SQL, y no es práctico para una Estructura de Entidad, soportar en forma nativa todas éstas. Más bien, el trayecto de la solicitud puede manejar una solicitud en la forma de un árbol de comando del proveedor del almacén. El proveedor del almacén posteriormente puede traducir el árbol de comando en un comando nativo. Esto se puede lograr traduciendo el árbol de comando en el dialecto SQL nativo del proveedor - por lo tanto de ahí el término SQLGen de esta fase. Posteriormente el comando resultante puede ser ejecutado para producir los resultados relevantes. PROCESAMIENTO DE ACTUALIZACIÓN Esta sección describe como se puede llevar a cabo el procesamiento de actualización en la Estructura de Entidad ADO.NET de ejemplo. En una modalidad, existen dos fases para actualizar el procesamiento, tiempo de compilación y tiempo de corrida. En la sección de Vistas Bi-direccionales aquí proporcionada, describimos el proceso para compilar la especificación de mapeo en una recolección de expresiones de vista. Esta sección describió como estas expresiones de vista son explotadas en el tiempo de corrida, para traducir las modificaciones de objeto llevadas a cabo en la capa de objeto (o actualizaciones SQL DML de Entidad en la capa EDM) en actualizaciones SQL equivalentes en la capa relación a la parte. Actualizaciones a través de Mantenimiento de Vista Una de las vistas explotadas en la arquitectura de mapeo ADO.NET son los algoritmos de mantenimiento de vista materializada que pueden ser apalancados para propagar actualizaciones a través de vistas bi-direccionales. Este proceso se ilustra en la figura 7. Las tablas dentro de una base de datos, tal como se ilustra en el lado derecho de la figura 7, mantienen datos persistentes. Un EntityContainer, tal como se ilustra en el lado izquierdo de la figura 7, representa un estado virtual de estos datos persistentes, ya que normalmente se materializa en el cliente únicamente una fracción delgada de las entidades de los EntitySets. La meta es traducir una actualización AEntities en el estado de Entidades en una actualización ATables en el estado persistente de las tablas. Este proceso es referido como un mantenimiento de vista en incremento, debido a que la actualización se lleva a cabo con base en la actualización de AEntities que representa los aspectos cambiados de una entidad. Esto se puede realizar utilizando los siguientes dos pasos: 1. Mantenimiento de vistas ZlTables = AUpdateViews(Entities, AEntities). 2. Desdoblamiento de vistas: \Tables = ZlUpdateViews (QueryViews(Tables), ¿.Entities).

En el Paso 1, se aplican algoritmos de mantenimiento de vista a las vistas de actualización. Esto produce un conjunto de expresiones delta, ..lUpdateViews, lo cual nos dice como obtener ilTables de .ÚEntities y capturas en pantalla de Entidades. Ya que lo último no se materializa completamente en el cliente, en el Paso 2 se utiliza el desdoblamiento de vista para combinar las expresiones delta con vistas de solicitud. Juntos, estos pasos generan una expresión que se toma como entrada al estado de la base de datos inicial y la actualización a las entidades, y computariza la actualización a la base de datos. Este método produce un algoritmo uniforme, puro que •trabaja tanto para el objeto - en un - tiempo como para actualizaciones a base de conjunto (es decir, las que se expresan utilizando expresiones de manipulación de datos) y apalanca tecnología de la base de datos robusto. En la práctica, el Paso 1 con frecuencia es suficiente para actualizar la traducción ya que muchas actualizaciones no dependen directamente del estado de la base de datos corriente; en dichas situaciones tenemos álables = AUpdateViews(¿\Entidties). Si \Entities se determina como un conjunto de modificaciones de objeto - en un - tiempo en entidades cache, entonces el Paso 1 puede ser optimizado en forma adicional ejecutado algoritmos de mantenimiento de vista directamente en las entidades modificadas, en lugar de computarizar la expresión ¿\UpdateViews. Actualizaciones de Traducción en Objetos Para ilustrar el método descrito anteriormente, se debe considerar el siguiente ejemplo el cual proporciona un bono y promoción para personas de ventas elegibles, quienes han estado con la compañía durante al menos 5 años. utilizando AdventureWorksDB aw = (new AdventureWorksDB (...) ) { / / Personas despedidas al menos hace 5 años Datetime d = DateTime. Today.AddYears (-5); ver personas from p in aw. Salespeople cuando p.HireDate < d seleccionar p; para cada uno (Salesperson p in people) { si (HRWebService.ReadyForPromotion(p) ) { p. Bonus += 10; p. Title = "Sénior Sales Representative"; } } aw.SaveChanges ( ); // push changes to DB AdventureWorksDB es una clase generada por una herramienta que se deriva de una clase de servicios de objetos genéricos, denominados ObjectContext, que aloja la conexión de la base de datos, espacio de trabajo de metadatos, y estructura de datos cache de objetos y expone el método SaveChanges. Como explicamos en la sección Servicios de Objeto, el cache del objeto mantiene una lista de entidades, cada una de las cuales está en uno de los siguientes estados: separados (del cache), agregados, no cambiados, modificados y eliminados. El fragmento de código anterior describe una actualización que modifica las propiedades del título y bono de los objetos ESalesPerson, los cuales se almacenan en las tablas SEmployees y SSalesPersons, respectivamente. El proceso para transformar las actualizaciones de objeto en actualizaciones de tabla correspondiente es activadas por la invocación al método SaveChanges, pueden comprender los siguientes cuatro pasos: Generación de Lista de Cambio. Una lista de cambios por entidad es creada a partir del cache de objeto. Las actualizaciones se representan como listas de elementos eliminados o insertados. Los objetos agregados se vuelven insertos. Los objetos eliminados se vuelven eliminaciones. Propagación de Expresión de Valor. Este paso toma la lista de cambios y las listas de actualización (mantenidos en el espacio de trabajo de los metadatos), y utilizando expresiones de mantenimiento de vista materializados increméntales AUpdateViews, transforma la lista de cambios de objetos en una secuencia de inserto de tabla de base algebraica y elimina las expresiones contra las tablas afectadas subyacente. Para este 5 ejemplo, las listas de actualización relevantes son UV2 y UV3 mostradas en la figura 6. Estas vistas son simplemente solicitudes de selección - proyecto, de modo que la aplicación de las reglas de mantenimiento de vista son sencillas. Obtuvimos las siguientes expresiones AUpdateViews, las cuales 10 son las mismas para inserciones (? + ) que para eliminaciones (?~): ASSalesPersons = SELECT p. Id, p.Bonus FROM óESalesPersons AS p ? SEmployees = SELECT p. Id, p. Title FROM ? ESalesPersons AS p ^ ^ ASContacts = SELECT p. Id, p.Name, p . Contact.Email, p. Contact. Phone FROM AESalesPersons AS p Se asume el lazo mostrado anteriormente actualizando la entidad E0,d = ESalesPersons(1 , 20, "", "Alice", Contact("a@sales", NULL)) to Enew= ESalesPersons( 1 , 30, "Sénior "Alice", Contact("a@sales", NULL)).

Posteriormente, el delta inicial es A + ESalesOrders = {Enew} para inserciones y A ESalesOrders = (E0|d) para eliminaciones. Obtuvimos A + SSalesPersons = {(1, 30)}, A SSales Persons = {(1, 20)}. Las inserciones y eliminaciones computarizadas en la tabla SSalesPersons, se combinan posteriormente en una sola actualización que ajusta el valor Bonus a 30. Las deltas en SEmployees son computarizadas en forma análoga. Para SContacts, obtuvimos A + SContacts = A'SContacts, de modo que no se requiere actualización. Además de computarizar los deltas en las tablas de base afectadas, esta fase es responsable de (a) la ordenación correcta en la cual las actualizaciones de tabla deben llevarse a cabo, tomando en consideración restricciones de integridad de referencia, (b) recuperación de claves generadas por almacén necesarias antes de presentar las actualizaciones finales a la base de datos, y (c) reunir la información para el control de concurrencia optimista. SOL DML o Generación de Invocaciones de Procedimiento Almacenados. Este paso transforma la lista de deltas insertados y eliminados más anotaciones adicionales relacionadas con el manejo de concurrencia en una secuencia de expresiones SQL DML o invocaciones del procedimiento almacenadas. En este ejemplo, las manifestaciones de actualización generadas para las salesperson afectadas son: COMIENZO DE TRANSACCION ACTUALIZAR [dbo] . [SSalesPersons] SET [Bonus]=30 EN CUANDO [SalesPersonlD]=1 ACTUALIZAR [dbo] . [SEmployees) CONJUNTO [Title] = N 'Sénior Sales Representative' EN CUANDO [EmployeelD]=1 FIN DE TRANSACCION Sincronización cache. Una vez que se han llevado a cabo las actualizaciones, el estado del cache sincronizado con el nuevo estado de la base de datos. Por lo tanto, si es necesario, se llevó a cabo un paso de procesamiento de mino-solicitud para transformar el nuevo estado relacional modificado a su entidad y estado de objeto correspondiente. METADATOS El subsistema de metadatos es análogo a un catálogo a base de datos, y se diseña para satisfacer las necesidades de metadatos de tiempo de diseño y tiempo de corrida de la Estructura de Entidad. Artefactos de Metadatos Los artefactos de metadatos pueden incluir, por ejemplo, lo siguiente: Esquema conceptual (archivos CSDL): el esquema conceptual puede ser definido en un archive CSDL (Lenguaje de Definición de Esquema Conceptual) y contiene dos tipos EDM (tipos de entidad, relaciones) y conjuntos de entidad que describen la vista conceptual de la aplicación de los datos. Esquema de Almacenamiento (archivos SSDL): La información del esquema de almacén (tablas, columnas, claves, etc) se puede expresar utilizando el término de vocabulario CSDL. Por ejemplo, EntitySets denota tablas y propiedades denota columnas. Estos pueden definirse en un archive SSDL (Lenguaje de Definición de Esquema de Almacén).

Especificación de mapeo C-S (archivo MSL): el mapeo entre el esquema conceptual y el esquema de almacén se captura en una especificación de mapeo, normalmente en un archivo MSL (Lenguaje de Especificación de Mapeo). Esta especificación es utilizada por el compilador de mapeo para producir las vistas de solicitud de actualización. Manifiesto del proveedor: Un Manifiesto de Proveedor puede proporcionar una descripción de la funcionalidad soportada por cada proveedor, y puede incluir la siguiente información de ejemplo: 1. Los tipos primitivos (varchar, int, etc.) soportados por el proveedor, y los tipos EDM (cadena, int32, etc.) que le corresponden . 2. Las funciones de incorporación (y sus signaturas) del proveedor. Esta información puede ser utilizada por el analizador Entity SQL como parte del análisis de solicitud. Además de estos artefactos, el subsistema de metadatos también puede mantener el seguimiento de las clases de objeto generadas, y el mapeo entre estos y los tipos de entidad conceptual correspondientes. Arquitectura de Servicios de Metadatos Los metadatos consumidos por la Estructura de Entidad pueden venir de diferentes fuentes en diferentes formatos. El subsistema de metadatos puede construirse sobre un conjunto de empaques de metadatos de bajo nivel unificados que permiten al tiempo de corrida de los metadatos operar en forma independiente de los detalles de los formatos/fuentes persistentes de metadatos diferentes. Los servicios de metadatos de ejemplo pueden incluir: Enumeración de diferentes tipos de metadatos. Sondeo de datos por clave. Búsqueda/navegación de metadatos. Creación de metadatos temporales (por ejemplo para procesamiento de solicitud). Sesión de cacheo y reutilización de metadatos independientes. El subsistema de metadatos incluye los siguientes componentes. El caché de metadatos, cachea los metadatos recuperados de diferentes fuentes, y proporciona a los consumidores un API común para recuperar y manipular los metadatos. Ya que los datos pueden ser representados en diferentes formas, y almacenados en diferentes ubicaciones, el subsistema de metadatos puede soportar en forma conveniente una interfase de carga. Los cargadores de metadatos implementan la interfase del cargador, y son responsables de cargar los metadatos de la fuente adecuada (archivos CSDL/SSDL, etc.). Un espacio de trabajo de metadatos agrega varias piezas de metadatos para proporcionar el conjunto completo de metadatos para una aplicación. Un espacio de trabajo de metadatos normalmente contiene información con respecto al modelo conceptual, el esquema de almacenamiento, las clases de objetos, y el mapeo entre estas construcciones. Herram ientas En una modalidad, una Estructura de Entidad también puede incluir una recolección de herramientas de tiempo-diseño para incrementar la productividad del desarrollo. Las herramientas de ejemplo son: Diseñador de modelo: Uno de los pasos tempranos en el desarrollo de una aplicación es la definición de un modelo conceptual. La Estructura de Entidad permite a los diseñadores y analistas de aplicaciones describir los conceptos principales de su aplicación en términos de entidades y relaciones. El diseñador del modelo es una herramienta que permite que esta tarea de modelado conceptual sea llevada a cabo en forma interactiva. Los artefactos del diseño son capturados directamente en el componente de Metadatos que puede persistir su estado en la base de datos. El diseñador de modelo también puede generar y consumir descripciones de modelo (especificados a través de CSDL), y puede sintetizar modelos EDM de los metadatos relaciónales. Diseñador de mapeo: Una vez que un modelo EDM ha sido diseñado, el desarrollador puede especificar como un modelo conceptual mapea una base de datos relacional. Esta tarea es facilitada por el diseñador de mapeo, el cual puede presentar una interfase del usuario, tal como se ilustra en la figura 8. El diseñador de mapeo ayuda a los desarrolladores a describir como las entidades y relaciones en un esquema de entidad presentados en el lado izquierdo de la interfase del usuario, mapean las tablas y columnas en la base de datos, tal como se refleja en un esquema de base de datos presentado en el lado derecho de la interfase del usuario en la figura 8. Los enlaces en la gráfica presentado en la sección media de la figura 8, visualizan las expresiones de mapeo especificadas en forma de declaración como ecualidades en las solicitudes de SQL de Entidad. Estas expresiones se convierten en la entrada al componente de compilación de mapeo bidireccional el cual genera las vistas de solicitud y actualización. Generación de código: El modelo conceptual EDM es suficiente para muchas aplicaciones, ya que proporciona un modelo de interacción familiar con base en patrones de código ADO.NET (comandos, conexiones, de datos). Sin embargo, muchas aplicaciones prefieren interactuar con datos en la forma de objetos tecleados fuertemente. La Estructura de Entidad incluye un conjunto de herramientas de generación de código que toman los modelos EDM como entrada y producen clases CLR tecleadas fuertemente para tipos de entidad. Las herramientas de generación de código también pueden generar un contexto de objeto tecleado fuertemente (por ejemplo Adventure WorksDB) el cual expone recolecciones tecleadas fuertemente de todos los conjuntos de entidad y relación definidos por el modelo (por ejemplo ObjectQuery<SalesPerson>). Aspectos v modalidades adicionales SERVICIOS DE MAPEO En una modalidad, un componente de mapeo tal como 114 en la figura 1, maneja todos los aspectos de mapeo y es utilizado internamente por el proveedor del cliente de la entidad 111. Un mapeo en forma lógica especifica una transformación entre construcciones en dos espacios de tipos potencialmente diferentes. Por ejemplo, una entidad - en espacio conceptual, tal como se utiliza el término anteriormente - puede ser especificado en términos de tablas de base de datos en espacio de almacenamiento, tal como se ilustra gráficamente en la figura 8. Los mapeos prescritos son aquellos en cuando el sistema determina automáticamente los mapeos adecuados para construcciones. Los mapeos no prescritos permiten a los diseñadores de la aplicación controlar varias facetas del mapeo. Un mapeo puede tener varias facetas. Los puntos de extremo del mapeo (entidades, tablas, etc.) el conjunto de propiedades mapeadas, el comportamiento de actualización, los efectos de tiempo, corridas tales como carga de retraso, el comportamiento de conflicto-resolución en la actualizaciones etc., son sólo una lista parcial de dichas facetas.

En una modalidad, el componente de mapeo 114 puede producir listas de mapeo. Considerar un mapeo entre el espacio de almacenamiento y el espacio de esquema. Una entidad está compuesta de filas de una o más tablas. Query Views expresa una entidad en el espacio de esquema como una solicitud en términos de tablas en espacio de almacenamiento. Las entidades pueden ser materializadas evaluando las listas de solicitud. Cuando los cambios a un grupo de entidades necesitan ser reflejadas nuevamente a las tablas de almacenamiento correspondientes, los cambios pueden ser propagados en un modo inverso a través de vistas de solicitud. Esto es similar al problema de actualización de vista en las bases de datos-un proceso de propagación de actualización que lleva a cabo en forma en forma lógica actualizaciones en el inverso(s) de la vista(s) de solicitud. Para este propósito, introducimos el concepto de vistas de actualización - estas vistas describen tablas de almacenamiento en términos de entidades, y pueden considerarse como inversos de la vista(s) de solicitud. Sin embargo, en muchos casos, lo que realmente nos interesa son cambios increméntales. Las Update Delta Views son vistas (solicitudes) que describen cambios a las tablas en términos de cambios a las recolecciones de entidad correspondientes. El procesamiento de actualización para recolecciones de entidad (u objetos de aplicación) por consiguiente, comprenden el cómputo de cambios adecuados a tablas evaluando las vistas delta de actualización, y posteriormente aplicando estos cambios a las tablas. En una forma similar, Query Delta Views describe cambios a las recolecciones de entidad en términos de cambios a las tablas subyacentes. Las invalidaciones, y más generalmente, notificaciones son escenarios que pueden requerir el uso de vistas delta de solicitud. Como con vistas en las bases de datos, las vistas de mapeo presentadas en las solicitudes posteriormente pueden estar compuestas con las solicitudes del usuario - que conducen a un tratamiento más generalizado de los mapeos. En forma similar, las vistas delta de mapeo expresadas con solicitudes, permiten un método más general y elegante para manejar las actualizaciones. En una modalidad, la potencia de las vistas de mapeo pueden ser restringidas. Las construcciones de solicitudes utilizadas en la vista de mapeo pueden ser únicamente un subconjunto de todas las construcciones de solicitud que están soportadas por la estructura de entidad. Esto permite expresiones de mapeo más simples y más eficientes especialmente en el caso de expresiones delta. Las vistas delta pueden ser computarizadas en el componente de mapeo 114 utilizando un esquema de cómputo de cambio algebraico para producir las vistas delta de actualización (y solicitud) procedentes de las vistas de actualización (y solicitud). Más adelante se describen aspectos adicionales del esquema de cómputo de cambio algebraico. Las vistas delta de actualización permiten que una Estructura de Entidad soporte actualizaciones traduciendo automáticamente los cambios de entidad elaborados por aplicaciones de cómputo en actualizaciones de nivel-almacén en una base de datos. Sin embargo en muchos casos, el mapeo debe ser aumentado con información adicional para desempeño y/o integridad de datos. En algunos casos, el mapeo directo de las actualizaciones o entidades a algunas o todas de sus tablas de almacén subyacentes pueden no ser deseables. En dichos casos, las actualizaciones deben ser tuneleadas a través de procedimientos-almacenados para permitir la validación de datos, así como mantener un límite confiable. El mapeo permite que las especificaciones de procedimientos almacenados manejen actualizaciones y solicitudes en las entidades. El mapeo también puede proporcionar soporte para un control de concurrencia optimista en los servicios de objeto 131. En forma específica, las propiedades de una entidad pueden ser marcadas como campos de concurrencia-control , tal como un campo de registros de tiempo o versiones, y los cambios a estos objetos sucederán únicamente si los valores de los campos de control de concurrencia en el almacén son los mismos que en la entidad. Se debe observar que tanto los campos de optimista-control de concurrencia son relevantes únicamente en la capa de objeto de aplicación, no en la capa específica de almacén 120. En una modalidad, los diseñadores de aplicación pueden utilizar el Lenguaje de Especificación de Mapeo (MSL) para describir varios aspectos de un mapeo. Una especificación de mapeo típica contiene una o más de las siguientes secciones. 1. Región de Data puede contener descripciones de clases, tablas y/o tipos EDM. Estas descripciones pueden describir clases/tablas/tipos existentes, o se pueden utilizar para generar dichas instancias. Los valores generados por el servidor, restricciones, claves primarias, etc. son especificados como parte de esta sección. 2. La sección de Mapeo describe los mapeos reales entre los espacios de tipo. Por ejemplo, cada propiedad de una entidad EDM es especificada en términos de una o más columnas de una tabla (o conjuntos de columna). 2. La región de Tiempo de corrida puede especificar varios botones que controlan la ejecución, por ejemplo, parámetros de control de concurrencia optimista y estrategia para retomar. Compilador de mapeo En una modalidad, el dominio que modela el componente de mapeo de herramientas 172 puede comprenden un compilador de mapeo que compila especificaciones de mapeo en una vista de solicitud, una vista de actualización y las vistas delta correspondientes. La figura 9 ilustra la compilación de MSL para generar las Vistas de Solicitud de Actualización. El trayecto de compilación lleva a cabo los siguientes pasos: 1. El Generador de Vista 902 invocado del API 900 traduce la información de mapeo de Object <? Entity 901 (especificado mediante MSL) y produce una vista de solicitud, una vista de actualización, y las expresiones delta correspondientes (solicitud de actualización) 904 en el espacio O <? E (Objeto de Entidad). Esta información puede ser colocada en el almacén de metadatos 908. 2. El Generador de Vista 906 traduce la información de mapeo Entity <? Store 903 (especificada mediante MSL) y produce una vista de solicitud, una vista de actualización y las expresiones delta correspondientes (solicitud de actualización) 907 en el E <? S en el espacio (Entidad a Almacén). Esta información puede ser colocada en el almacén de metadatos 908. 3. El componente de Análisis de Dependencia 909 inspecciona las vistas producidas por el Generador de Vista 906 y determina un orden de dependencia consistente 910 para actualizaciones que no violan la integridad de referencia y otras restricciones. Esta información puede ser colocada en el almacén de metadatos 908. 4. Las vistas, las expresiones delta y el orden de dependencia 908 posteriormente se pasan en el componente de Servicios de Metadatos (112 en la figura 1). Procesamiento de actualización Esta sección describe el trayecto de procesamiento de actualización. En una modalidad, la Estructura de Entidad puede soportar dos tipos de actualizaciones. Los cambios de objeto simple son cambios elaborados a objetos individuales mientras se navega la gráfica del objeto. Para cambios de objetos simples, el sistema mantiene el rastreo de los objetos que han sido creados, actualizados y eliminados en la transacción corriente. Esto está disponible únicamente en la capa(s) del objeto. Los Cambios a base de solicitud son cambios llevados a cabo emitiendo una manifestación de actualización/eliminación con base en la solicitud de objeto, por ejemplo, tal como se realiza en las bases de datos de relación para actualizar tablas. Los Proveedores de Objeto tales como 131 en la figura 1 pueden ser configurados para soportar cambios de objeto simple, pero no cambios a base de solicitud. El Proveedor de Cliente de Entidad 111, por otra parte, puede soportar cambios a base de solicitud, pero no cambios de objeto simple. La figura 10, proporciona una ilustración de procedimiento de actualización en una modalidad de ejemplo. En la figura 10, un usuario 1001 de una aplicación en la capa de aplicación 1000 puede salvas cambios 1002 para los datos manipulados por dicha aplicación. En la capa de objeto-proveedor 1010, se compila una lista de cambio 1011. El agrupamiento de cambio 1012 se lleva a cabo en la lista de cambio. Un manejo de restricción 1013 puede producir información de restricción de un modelo de dependencia 1022 que es guardado en el almacén de metadatos 1017. Se ejecutan operaciones extendidas 1014. Se genera una expresión de control de concurrencia 1015, y un modelo de concurrencia 1023 puede ser salvado en el almacén de metadatos 1017. El objeto para el convertidor de entidad 1016 puede guardar el objeto de las expresiones delta de entidad 1024 del almacén de metadatos 1017. Un árbol de expresión de entidad 1018 se pasa a la capa de Proveedor 1030. Un divisor de actualización selectivo 1031 puede seleccionar ciertas actualizaciones y dividirlas según sea necesario. Un convertidor de almacén EDM 1032 puede guardar expresiones delta de la entidad-al almacén 1033 en un almacén de metadatos 1036. Un componente de desdoblamiento de vista de solicitud 1035 puede guardar las vistas de mapeo de solicitud 1035 en el almacén de metadatos 1036. La entidad para almacenar la compensación 1037 se lleva a cabo, y el árbol de expresión del almacén 1038 se pasa a la capa de almacén-proveedor 1040. En la capa del proveedor de almacén 1040, un componente simplificador 1041 puede operar primero, seguido de un componente de generación SQL 1042, que genera actualizaciones SQL 1043 que serán ejecutados en la base de datos 1044. Cualesquiera resultados de actualización pueden pasarse a un componente 1039 en la capa de proveedor EDM 1030 para manejar los valores generados por el servidor. El componente 1039 puede pasar los resultados a un componente similar en la capa de objeto-proveedor 1021. Finalmente, cualquiera resultados o confirmación de actualización 1003 es regresada a la capa de aplicación. Tal como se describió anteriormente, las vistas delta de actualización se generan como parte de la compilación de mapeo. Estas vistas se utilizan en los procesos de actualización para identificar los cambios a las tablas en el almacén. Para un conjunto de tablas relacionadas en el almacén, la Estructura de Entidad puede aplicar convenientemente actualizaciones en cierto orden. Por ejemplo, la existencia de descripciones de clave extraña puede requerir que se apliquen cambios en una secuencia en particular. La fase de análisis de dependencia (parte de una compilación de mapeo) identifica cualesquiera requerimientos de ordenación de dependencia que pueden ser computarizados en el tiempo-compilación. En algunos casos, la técnica de análisis de dependencia estática puede no ser suficiente, por ejemplo, con restricciones de integridad referenciales cíclicas (o restricciones de integridad autorreferenciales). La Estructura de Entidad adopta un método optimista, y permite que dichas actualizaciones avancen. En el tiempo de corrida, si se detecta un ciclo, surge una excepción. Tal como se ilustra en la figura 10, el trayecto de procesamiento de la actualización para actualizaciones a base de instancia en la capa de aplicación 1000 tiene los siguientes pasos. Agrupamiento de cambios 1012: Se agrupan los cambios de acuerdo con las diferentes recolecciones de objeto de un rastreador de cambio, por ejemplo, todos los cambios para la recolección Persona son agrupados en un conjunto de inserto, eliminación y una actualización de dicha recolección. Manejo de restricciones 1013: Este paso lleva a cabo cualesquiera operaciones que compensan el hecho de que no se ejecuta una lógica de negocios en la capa de valor-esencialmente, permite que la capa de objeto se extienda al conjunto de cambio. La compensación de cascada-eliminación y la ordenación de dependencia (con respecto a las restricciones EDM), se llevan a cabo en la presente invención. Ejecución de operación extendida 1014: Las operaciones extra (por ejemplo eliminadas) se ejecutan de modo que pueda correr la lógica de negocios correspondiente. Generador de expresión de control de concurrencia 1015: Para detectar si los objetos modificados están añejos, podemos generar expresiones que realizan la columna de registro de tiempo o un conjunto de columnas tal como se especifica en el mapeo de metadatos. Conversión de objeto a EDM 1016: Las listas de cambio especificas en términos de conjuntos de objeto de inserto, eliminación y actualización ahora son convertidas utilizando expresiones delta de mapeo almacenadas en el almacén de metadatos 1017, las cuales se almacenan después de la compilación de mapeo descrita con referencia a la figura 9. Después de esta paso, los cambios están disponibles árboles de expresión 1018 expresados únicamente en términos de entidades EDM. El árbol de expresión del paso 1018 posteriormente se pasa al proveedor EDM en la capa EDM-proveedor 1030. En el proveedor EDM, el árbol de expresión es procesado y los cambios son presentados al almacén. Se debe observar que este árbol de expresión 1018 también puede ser producido en otra forma - cuando una aplicación se programa directamente contra el proveedor EDM, se puede ejecutar una expresión DML contra éste. Dicha expresión DML se convierte primero a través de proveedor EDM en un árbol de expresión EDM 1018. El árbol de expresión obtenido de una expresión DML o de la capa de aplicación 1000 es procesado en la siguiente forma: Divisor de actualización selectivo 1031: En este paso, algunas de las actualizaciones se dividen en insertos de eliminaciones. En general, propagamos actualizaciones ya que están en las capas inferiores. Sin embargo, en ciertos casos, puede no ser posible llevar a cabo dichas actualizaciones, ya sea debido a que las reglas de expresión delta no han sido desarrolladas para dicho caso, debido a que la traducción correcta realmente da como resultado insertos y/o eliminaciones a las tablas de base. Conversión de EDM a Almacén 1032: El árbol de expresión de nivel-EDM 1018 es traducido en el espacio de almacén utilizando las expresiones delta del mapeo adecuado. Desdoblamiento de Vista de Mapeo de solicitud 1034: El árbol de expresión 1018 puede contener algunos conceptos de nivel de EDM. Para eliminarlos, desdoblamos el árbol de expresión utilizando la Vista de Mapeo de Solicitud 1035 para obtener un árbol 1038 en términos únicamente de conceptos de nivel-Almacén. El árbol 1038 es procesado opcionalmente a través de un componente de compensación E-S 1037. El árbol de expresión 1038 el cual ahora está en términos de espacio de almacén, es proporcionado al proveedor de almacén en la capa de proveedor de historia 1040, el cual lleva a cabo los siguientes pasos: Simplificación 1041: El árbol de expresión es simplificado utilizando reglas de traducción de expresión lógicas. Generación SQL 1042: Debido al árbol de expresión, el proveedor de almacén genera el SQL real 1043 del árbol de expresión 1038.

Ejecución SQL 1044: Los cambios reales se llevan a cabo en la base de datos. Valores generados por el servidor: Los valores generados por el servidor son regresados a la capa EDP 1030. El proveedor 1044 pasa los valores generados por el servidor a un componente 1039 en la capa 1030 que los traduce en conceptos EDM utilizando un mapeo. La capa de aplicación 1000 recoge estos cambios 1003 y los propaga a conceptos de nivel de objeto que serán instalados en las diversas aplicaciones y objetos utilizados en dicha capa. En muchos casos, las tablas de almacén pueden no ser directamente actualizables debido a las políticas de Administrador de Base de Datos (DBA), por ejemplo. Las actualizaciones en las tablas pueden ser posibles únicamente a través de procedimientos almacenados, de modo que se pueden llevar a cabo ciertas revisiones de validación. En estas situaciones, el componente de mapeo debe traducir los cambios de objeto en invocaciones a estos procedimientos almacenados en lugar de ejecutar expresiones SQL de inserto, eliminación y actualización "sin procesar". En otros casos, los procedimientos "almacenados" pueden ser especificados en EDP 1010 o en la capa de aplicación 1000 - en dichos casos, el componente de mapeo debe traducir los objetos modificados en espacio EDM, y posteriormente invocar el procedimiento adecuado. Para habilitar estos escenarios, el MSL permite que se especifiquen procedimientos almacenados como parte del mapeo; además, el MSL también soporta mecanismos para especificar como se mapean varias columnas de base de datos a los parámetros de procedimientos almacenados. La capa EDP 1010 soporta un control de concurrencia optimista. Cuando el CDP envía un conjunto de cambios al almacén, las filas cambiadas pueden haber sido ya modificadas por otra transacción. El CDP debe soportar una forma para que los usuarios tengan la capacidad de detectar dichos conflictos, y posteriormente resolver dichos conflictos. El MSL soporta mecanismos simples - registro de tiempo, versión-número, columnas cambiadas, columnas-para detección de conflictos. Cuando se detectan conflictos, surge una excepción, y los objetos de conflicto (o entidades EDM) están disponibles para la resolución de conflicto por parte de la aplicación. REQUERIMIENTOS DE MAPEO DE EJEMPLO La infraestructura de mapeo puede proporcionar en forma conveniente la capacidad de traducir varias operaciones del espacio de aplicación al espacio relacional, por ejemplo, las solicitudes de objeto escritas por un desarrollador traducida en el espacio relacional (almacenamiento). Estas traducciones deben ser eficientes sin un copiado de datos excesivo. El mapeado puede proporcionar traducciones para las siguientes operaciones de ejemplo: 1. Solicitudes: Solicitudes de objeto que necesitan ser convertidas en un dominio de relación de programa de respaldo y registros obtenidos de la base de datos necesarias para ser convertidos en objetos de aplicación. Se debe observar que estas solicitudes deben ser solicitudes a base de conjunto (por ejemplo secuencias CSQL o C#) o base de navegación (por ejemplo siguiendo las referencias). 2. Actualizaciones: Los cambios elaborados por una aplicación a esos objetos necesitan ser propagados de regreso a la base de datos. Nuevamente, los cambios elaborados a los objetos pueden ser a base de conjunto o a objetos individuales. Otra dimensión de considerar, es si los objetos que están siendo modificados están cargados completamente en la memoria o cargados parcialmente (por ejemplo un manejo de recolección de un objeto puede no estar presente en la memoria). Para actualizaciones a objetos cargados parcialmente, pueden ser preferibles diseños en los cuales estos objetos no se requiere que estén cargados completamente en la memoria. 3. Invalidaciones y notificaciones: Las aplicaciones que corren en la hilera media o hilera de cliente pueden desear ser notificadas cuando algunos objetos cambian en el backend. Por lo tanto, el componente de mapeo-OR debe traducir los registros en el nivel de objeto al espacio relacional; en forma similar, cuando se reciben mensajes a través de un cliente con respecto a registros modificados, el mapeador-OR debe traducir estas notificaciones en cambios de objeto. Se debe observar que WinFS soporta dichas "notificaciones" a través de su mecanismo - sin embargo, en dicho caso, el mapeo es prescrito, en cuando la Estructura de Entidad debe soportar Observadores en un mapeo no prescrito. 4. Un mecanismo similar a la notificación también es necesario para invalidar objetos anejos de un proceso de Estructura de Entidad que corre en la hilera media o de cliente -si la Estructura de Entidad proporciona soporte para control de concurrencia optimista para manejar lecturas/escrituras en conflicto, las aplicaciones pueden asegurar que los datos cacheados en la Estructura de Entidad sean razonablemente recientes (de modo que las transacciones no sean abortadas debido a lecturas/escrituras de objetos); de lo contrario, pueden tomar decisiones en los datos antiguos y/o tener que abortar sus transacciones posteriormente. Por lo tanto, igual que las notificaciones, el mapeador-OR puede tener que traducir mensajes de "invalidación" de los servidores de la base de datos en invalidaciones de objeto. 5. Soporte/restauración/Sync: El soporte y reflejo de Entidades son dos características que pueden ser incorporadas en algunas modalidades. Los requerimientos para que estas características pueden traducirse simplemente en una solicitud especializada en Entidades desde la perspectiva del mapeador- OR; de lo contrario, se puede proporcionar un soporte especial para dichas operaciones. En forma similar, sync pueden necesitar soportarse del procesador de mapeo-OR para traducir los cambios de objeto, conflictos, etc., al almacén y viceversa. 6. Participación en control de concurrencia: El mapeador OR puede soportar de forma conveniente diferentes formas a través de las cuales se puede utilizar el control de concurrencia optimista a través de una aplicación, por ejemplo, utilizando un valor de registro de tiempo, algún grupo de campos en particular, etc. El mapeador OR debe traducir la información de control de concurrencia tal como propiedades de registro de tiempo hacia/desde el espacio de objeto y desde/hacia el espacio relacional. El mapeador-OR puede incluso proporcionar soporte a un control de concurrencia pesimista (por ejemplo tipo Hibernate). 7. El reporte de error de tiempo de corrida. En la modalidad de ejemplo ilustrada en la presente invención, los errores de tiempo de corrida normalmente ocurrirán en el nivel de almacenamiento. Estos errores pueden ser traducidos en el nivel de aplicación. El mapeador OR debe ser utilizado para facilitar estas traducciones de error. ESCENARIOS DE MAPEO Antes de describir los escenarios del desarrollador de ejemplo que una Estructura de Entidad puede soportar, ilustraremos varias partes lógicas del mapeador-OR. En una modalidad, existen cinco partes en un mapeo-OR tal como se ilustra en la figura 11: 1. Objetos/clases/XML (espacio de aplicación aka) 1101: El desarrollador especifica las clases y objetos en un lenguaje de elección - finalmente, estas clases se compilan en ensambles CLR, y son accesibles a través de la reflexión de APIs. Estas clases incluyen miembros persistentes y no persistentes también; asimismo, los detalles específicos de lenguaje pueden ser incluidos en esta parte. 2. Esquema del modelo de datos de entidad (espacio conceptual) 1102: El espacio EDM es utilizado por el desarrollador para modelar datos. Tal como se describe anteriormente, la especificación del modelo de datos se realiza en términos de tipos EDM, relaciones entre entidades a través de asociaciones, herencias, etc. 3. Esquema de bases de datos (espacio de almacenamiento aka) 1103: En este espacio, el desarrollador especifica como las tablas son distribuidas; las restricciones tales como restricciones de clave extraña y restricciones de clave primaria también se especifican aquí. La especificación en este espacio puede tomar la ventaja de características específicas del proveedor, por ejemplo, tablas anidadas nested, UDTS, etc. 4. Mapeo de objeto-EDM 1104: Este mapeo especifica como varios objetos y Entidades EDM se relacionan entre sí, por ejemplo, una formación puede ser mapeada a una asociación de uno a muchos. Se debe observar que no es esencial que este mapeo sea trivial/identidad, por ejemplo, múltiples clases pueden mapear a un tipo EDM determinado o viceversa. Se debe observar que podemos o no tener redundancia/desnormalización en estos mapeos (por supuesto, con la desnormalización, es posible correr en problemas para mantener consistentes los objetos/entidades). 5. Mapeo de EDM-almacén 1105: Este mapeo especifica como las entidades EDM y los tipos se relacionan con diferentes tablas en la base de datos, por ejemplo, aquí se pueden utilizar diferentes estrategias de mapeo de herencia. Un desarrollador puede especificar uno o más de los espacios 1101, 1102 ó 1103 y los mapeos correspondientes entre uno o más mapeos entre ellos. Si está faltando cualquier espacio de datos, el desarrollador puede proporcionar indicios en cuanto a como generar dicho espacio o esperar que EDP genere dichos espacios en forma automática, con los mapeos prescritos correspondientes. Por ejemplo, si un desarrollador especifica clases, tablas y mapeo existente entre ellos, el EDP genera el esquema EDM interno y los mapeos de objetos-EDM y EDM-almacén correspondientes. Por supuesto, en el caso más general, el desarrollador puede tener un control completo y especificar los modelos de datos en estos tres espacios junto con los dos mapeos. La tabla que se encuentra a continuación muestra los diferentes escenarios soportados en el EDP. Esta es la lista exhaustiva de casos en cuando el desarrollador puede especificar o no objetos, entidades EDM, tablas, etc.

Dependiendo de los escenarios anteriores que el EDP desee soportar, tendremos que proporcionar herramientas para producir los espacios de datos y mapeos no especificados (en una forma prescrita o con base en las indicaciones, si se proporciona). El procesador OR interno asume que las 5 partes del mapeo (objetos, especificaciones EDM, tablas, mapeo OE, mapeo ES) están disponibles. Por lo tanto, el diseño de mapeo debe soportar el caso más general, es decir (G) en la tabla anterior. LENGUAJE DE ESPECIFICACIÓN DE MAPEO Una de las partes "visibles" del mapeador-OR desde la perspectiva del desarrollador es el lenguaje de especificación de mapeo o el MSL - el desarrollador especifica como varias partes del mapeo están atadas entre sí utilizando este lenguaje. Los controles de tiempo de corrida (por ejemplo, aspectos de retomar retrasos, control de concurrencia optimista) también se especifican utilizando MSL. Dividimos el mapeo en tres diferentes conceptos - cada concepto se dirige a un diferente aspecto del proceso de mapeo. Se debe observar que no se manifiesta si estas especificaciones están almacenadas en un archivo simple, en múltiples archivos o especificados a través de una reposición extraña (por ejemplo, para la especificación de datos). 1. Especificación de datos: En esta región, un desarrollador puede especificar las descripciones de clase, descripciones de tabla y descripciones de EDM. Estas descripciones pueden proporcionarse como especificaciones para propósitos de generación o pueden ser especificaciones para tablas/objetos que ya existen. 2. Las especificaciones de objeto y tabla pueden describirse en nuestro formato o pueden importarse de una reposición de metadatos extraña, utilizando alguna herramienta de importación. Se debe observar que la especificación de los valores generados por el servidor, restricciones, claves primarias, etc. se realizan en esta sección (por ejemplo en la especificación EDM, las restricciones se especifican como parte de la especificación de tipo). 2. Especificaciones de mapeo: El desarrollador especifica mapeos para varios objetos, tipos EDM y tablas. Permitimos que los desarrolladores especifiquen los mapeos de objeto-EDM, EDM-almacén y objeto-almacén. Esta sección trata de tener una mínima redundancia con la especificación de datos. En los tres casos de mapeo (OS, ES y OE), especificamos mapeos para cada clase ya sea "directamente" en el nivel superior o "indirectamente" dentro de otra clase. En cada mapeo, se mapea un campo/propiedad a otro campo, función escalar de campos, un componente o un conjunto. Para permitir las actualizaciones, estos mapeos necesitan ser bidireccionales, es decir, ir del objeto al espacio de almacén y en el regreso no debe perderse ninguna información; también se puede permitir mapeos no bidireccionales, tal como que los objetos son únicamente de lectura. Mapeos de objeto-EDM : En una modalidad, especificamos un mapeo para cada objeto en términos de tipos EDM. Mapeos EDM-almacén: En una modalidad, especificamos un mapeo para cada entidad en términos de tablas. Mapeos objeto-almacén: En una modalidad, especificamos un mapeo para cada objeto en términos de tablas. 3. Especificación de tiempo de corrida: En una modalidad, permitimos que los desarroMadores especifiquen varios botones que controlan la ejecución, por ejemplo, parámetros de control de concurrencia optimista, y estrategias para retomar. Aquí existe un ejemplo de un mapeo de archivo para un caso en cuando un objeto OPerson, contiene un conjunto de direcciones. Este objeto es mapeado a tipo de entidad EDM y el conjunto es mapeado a un tipo de conjunto en línea. Los datos se almacenan en dos tablas - una para las personas y otras para direcciones. Tal como se manifestó anteriormente, no es esencial que el desarrollador especifique todos los objetos, tipos EDM y tablas - sólo mostramos el caso (G) de la tabla anterior. Se supone que las especificaciones no describen alguna sintaxis específica; significa que ilustran y permiten el diseño de un sistema alrededor de conceptos aquí descritos. Especificaciones de objeto Especificaciones EDM Especificamos un tipo de entidad CPerson y un tipo en línea Caddress, de modo que cada CPerson tenga una recolección de partidas CAddress.

Especificaciones de almacén Especificamos dos tipos de tabla SPerson y SAddress junto con sus claves (tpid y taid).

Mapeos de Objeto-CDM El siguiente mapeo para OPerson, indica que el tipo de objeto OPerson es mapeado a la Entidad CPErson. La lista que después se especifica como cada campo de OPerson es mapeada - el nombre es mapeado al nombre y la recolección de direcciones es mapeada a la recolección de dirección.

Mapeos EDM- Almacén Tipo de Entidad de EDM CPerson es mapeado al tipo de tabla SPerson con su clave y los atributos cname de nombre. InlineType CAddress se mapea en SAddress en una forma simple. Se debe observar que la tabla SAddress puede almacenar una clave extraña en SPerson; esta restricción puede haber sido especificada en la especificación de modelo de datos de la tabla OPerson, no en el mapeo.

Especificaciones de tiempo de corrida El desarrollador puede desear especificar el control de concurrencia optimista en OPerson para que sea realizado en los campos de pid y ñame y nombre. Para OAddress, puede especificar el control de concurrencia en el campo de estado.

REVISIÓN DE DISEÑO DE MAPEO La mayor parte de las tecnologías de mapeo OR, tal como Hibernate y ObjectSpaces, tienen un inconveniente importante -manejan actualizaciones en forma relativamente ad-hoc. Cuando los cambios al objeto necesitan ser regresados al servidor, los mecanismos utilizados por estos sistemas manejan actualizaciones en una base caso por caso, limitando de esta forma la capacidad de extensión de sistema. Conforme más casos de mapeo son soportados, el trayecto y la actualizaciones se vuelven más complejos y es difícil componer los mapeos para actualizaciones. Conforme el sistema evoluciona, esta parte del sistema se vuelve muy difícil de cambiar, asegurando al mismo tiempo que sea correcta. Para evitar dichos problemas, utilizamos un método novedoso en cuando llevamos a cabo el proceso de mapeo utilizando dos tipos de "vistas de mapeo" - uno que nos ayuda a traducir las solicitudes y el otro que ayuda a traducir las actualizaciones. Tal como se muestra en la figura 12, cuando una especificación MSL 1201 es procesada por el EDP, genera dos vistas 1201 y 1203 internamente para la ejecución del procesador de mapeo del centro. Como podremos apreciar posteriormente, modelando el mapeo en términos de estas vistas, tenemos la capacidad de apalancar el conocimiento existente de la tecnología de vista materializada en bases de datos relaciónales. En particular, tomamos la ventaja de técnicas de mantenimiento - vista increméntales par modelar actualizaciones en una forma correcta, elegante y extensible. Describimos a continuación estos dos tipos de vistas de mapeo. Utilizamos la anotación de Vistas de Mapeo de Solicitud o QMViews para mapear los datos de la tabla a objetos y Vistas de Mapeo de Actualización o UMViews para mapear los cambios de objeto a actualizaciones de tabla. Estas vistas son nombradas debido a la razón (principal) de que porque fueron construidas. La Vista de Solicitud traduce solicitudes de objeto en solicitudes relaciónales y convierte los registros relaciónales que entran a objetos. Por lo tanto, para el mapeo EDM-Almacén, cada QView muestra como un tipo EDM es construido a partir de varias tablas. Por ejemplo, si una entidad de Persona es construida de la unión de dos tablas T_P y T_A, especificamos Persona en términos de una unión entre estas dos tablas. Cuando una solicitud es requerida en la recolección de Persona, el QMView para Persona, substituye Persona con una expresión en términos de T_P y T_A; esta expresión posteriormente genera el SQL. La solicitud posteriormente es ejecutada en la base de datos; cuando se recibe una respuesta por parte del servidor, el Q View materializa los objetos de los registros regresados. Para manejar actualizaciones de objetos, nos podemos imaginar cambios a través de QMViews y al apalancamiento de la tecnología de "actualizaciones de vista" desarrollado para bases de datos relaciónales. Sin embargo, las vistas actualizables tienen un número de restricciones impuestas, por ejemplo, el Servidor SQL no permite que múltiples tablas de bases sean modificadas a través de una actualización de vista. Por lo tanto, en lugar de restringir los tipos de mapeo permitidos en el SQL, las modalidades de la presente invención apalancan otro aspecto de tecnología de vista materializada que tiene muchas menos restricciones - mantenimiento de vista. Especificamos las Vista de Mapeo de Actualización o UMViews para expresar cada tabla en el sistema en términos de tipos EDM, es decir, en cierto sentido, UMViews son lo inverso de QMViews. Un UMViews para un tipo de tabla en el límite de EDM-almacén presenta una forma mediante la cual se utilizan diferentes tipos EDM para construir las columnas del tipo de dicha tabla. Por lo tanto, si hemos especificado que el tipo de objeto Persona mapea a las tablas tipos T_P y T_A, no únicamente generamos un QMViews para el tipo Persona en términos de T_P y T_A, sino también generamos un UMViews que especifica como una fila de T_P puede ser construida debido a un tipo de objeto de Persona (similarmente a T_A). Si una transacción crea, elimina o actualiza algunos objetos de Persona, utilizamos las Vistas de Actualización para traducir dichos cambios de objetos en expresiones de inserto, actualización y eliminación SQL en T_P y T_A - las UMViews nos ayudan a llevar a cabo estas actualizaciones, ya que nos indican como se obtienen los registros relaciónales de los objetos (a través de tipos CDM). Las figuras 13 y 14 muestran, en un mayor nivel, como QMV y UMViews se utilizan en la traducción de solicitudes y consultas. Debido a este método para modular tablas como vistas en objetos, el proceso de propagar actualizaciones en objetos de nuevo a las tablas es similar al problema de mantenimiento de vista, en cuando los objetos con las "relaciones de datos" y las tablas son las "vistas". Existe una gran cantidad de literatura de base de datos que se dirigen al problema de mantenimiento de vista y podemos apalancar esto para cuatro propósitos. Por ejemplo, existe un cuerpo de trabajo significativo que muestra como los cambios increméntales a las relaciones de base pueden ser traducidos en cambios increméntales en las vistas. Utilizamos un método algebraico para determinar las expresiones necesarias para llevar a cabo actualizaciones increméntales en las vistas - nos referimos a estas expresiones como expresiones delta. Utilizando un método algebraico, en forma opuesta a uno de procedimiento, para al mantenimiento de vista incremental es adecuado ya que es más adaptable a simplificaciones de optimización y actualización. En general, las ventajas de utilizar vistas de mapeo en el procesador central de EDP incluyen: 1. Las Vistas proporcionan una cantidad significativa de potencia y flexibilidad para expresar mapas entre objetos y relaciones. Podemos iniciar con un lenguaje de expresión-vista restringido en la parte central del procesador de mapeo-OR. Conforme lo permita el tiempo y los recursos, la potencia de las vistas puede ser utilizada para evolucionar suavemente el sistema. 2. Las vistas son conocidas por componer en forma muy elegante solicitudes, actualizaciones y vistas por sí mismas. La capacidad de composición, especialmente con respecto a actualizaciones, fue un aspecto problemático con algunos de los métodos de mapeo-OR implementados anteriormente. Al adoptar una tecnología a base de vista, podemos evitar dichos aspectos . Utilizando la noción de vistas se permite que apalanquemos un cuerpo de trabajo significativo en la literatura de la base de datos. ELABORACION DE CAPAS ARQUITECTONICAS PARA ACTUALIZACIONES Un aspecto importante de considerar en la implementación de aspectos de la presente invención, es que la potencia del lenguaje de vista de mapeo (o MVL) en el cual se expresan vistas de mapeo Solicitud y Actualización. Es casi lo suficientemente potente para capturar todos los mapeos no prescriptivos entre los objetos y EDM junto con los mapeos entre EDM y el almacén. Sin embargo, para un MVL soporta todos los conceptos CLR y EDM no relaciónales en forma nativa necesitamos diseñar expresiones o reglas de actualización de vista increméntales para todas de dichas construcciones. En particular, una modalidad de ejemplo puede requerir reglas de actualización para los siguientes operados/conceptos de álgebra no relaciónales: Tipos complejos - acceso a partes objetos, constructores de registros, allanamiento, constantes complejas, etc. Recolecciones - anidamiento y no anidamiento, construcción/allanamiento de conjuntos, aplicación cruzada, etc. Formaciones/listas - el orden de los elementos no es una construcción relacional; aparentemente, las álgebras para listas ordenadas son muy complejas. Otras construcciones EDM y construcciones de objetos en el CLR/C# que no necesitan ser modeladas. Es posible desarrollar expresiones delta para actualizaciones increméntales para estas construcciones. El problema principal con el soporte de un conjunto grande de construcciones en forma nativa en el MVL, es que pueden complicar considerablemente el procesador central. En una modalidad, un método más deseable puede ser elaborar capas del sistema de modo que el "procesador de mapeo central" maneje un MVL simple y posteriormente elabore capas de las construcciones no relaciónales en la parte superior de este centro. Describimos dicho diseño a continuación. Nuestro método para que el mapeo-OR atienda los problemas anteriores "elaborando capas" - en un tiempo de compilación, primero traducimos cada construcción no relacional en el objeto EDM y espacios de base de datos (WinFS soporta anidamiento, UDTS, etc.) en una construcción relacional correspondiente en una forma prescrita y posteriormente llevar a cabo las traducciones no prescritas requeridas entre las construcciones relaciónales. Nos referimos a este método como el método de mapeo de vista en capas. Por ejemplo, si una CPerson contiene una recolección de direcciones, primero traducimos esta recolección en una construcción relacional como una asociación de uno a muchos, y posteriormente se lleva a cabo la traducción no prescrita requerida para las tablas en el espacio relacional. Fragmentación MVL El MVL se fragmentó en dos capas - una que trata con el mapeo no prescritito real en términos relaciónales y una traducción prescriptiva de construcciones no relaciónales en términos relaciónales. El primer lenguaje es referido como R-MVL (para M VL-relacional) y los mapeos correspondientes son denominados mapeos R-MVL; en forma similar, el último lenguaje (más potente) es referido como N-MVL (para MVL no relacional) y los mapeos son denominados mapeos N-MVL. En una modalidad, se proporciona mapeo estructurando el diseño de modo que todas las construcciones no relaciónales sean empujadas a los finales de los trayectos de la solicitud y actualización. Por ejemplo, la materialización de objetos puede implicar construir objetos, formaciones, señaladores, etc. -dichos "operadores" son empujados en la parte superior del trayecto de la solicitud. En forma similar, cuando ocurren actualizaciones en objetos, producimos cambios en objetos no relaciónales (por ejemplo recolecciones anidadas, formaciones) al comienzo de la trayectoria y posteriormente se preparan estos cambios a través del trayecto de actualización. En sistemas tipo WinFS, necesitamos traducir al final del trayecto de actualización a UDTs). Restringiendo los mapeos no prescritos a R-MVL, ahora tenemos un pequeño conjunto de construcciones relaciónales para las cuales necesitamos reglas de manteniendo de vista incremental - dichas reglas que han sido desarrolladas para bases de datos relaciónales. Hacemos referencia a construcciones/esquemas simplificados que son permitidos en R-MVL como el Esquema Expresado en Forma Relacional o RES. Por lo tanto, cuando algunas construcciones no relaciónales necesitan ser soportadas (es decir) en el dominio objeto, llegamos con una construcción RES correspondiente y una traducción prescrita entre el objeto y la construcción RES, por ejemplo, traducimos una recolección de objeto a una asociación uno a muchos en el espacio RES. Además, para propagar actualizaciones en construcciones no relaciónales N, llegamos con expresiones delta que traducen insertos, eliminaciones de actualizaciones de N a N's de la construcción RES correspondiente. Se debe observar que estas expresiones delta son prescritas y son generadas por nosotros en el tiempo de diseño, por ejemplo sabemos como empujar cambios a una recolección en una asociación uno a muchos. Las expresiones delta para mapeos no prescritos reales son generados automáticamente utilizando reglas de mantenimiento de vista incremental para bases de datos relaciónales. Esta metodología en capas no únicamente elimina el requerimiento de llegar con reglas de mantenimiento de vista increméntales generalizadas para una plétora de construcciones no relaciónales, sino también simplifica el trayecto de actualización interna. Se debe observar que nuestro método de mapeo en capas tiene un beneficio similar en cuanto al trayecto de notificación también - cuando los cambios en dúplex son recibidos del servidor necesitamos traducirlos en cambios increméntales en objetos. Este es el mismo requerimiento que el del trayecto de actualización, excepto que necesitamos utilizar las Vistas de Mapeo de Consulta para propagar estos cambios, es decir generamos expresiones delta para las QMViews. Además de simplificar el trayecto de la actualización y notificaciones, la elaboración de capas de MVL tiene una ventaja importante - permite que "los lenguajes superiores" (objetos, EDM, base de datos) evolucionen sin tener un impacto significativo en el procesador de mapeo central. Por ejemplo, si se agrega un nuevo concepto a EDM, todo lo que necesitamos hacer es llegar con una forma prescrita para convertirla en un RES correspondiente para dicha construcción. En forma similar, si se encuentra un concepto no relacional en el servidor SQL (por ejemplo UDTs, anidamiento), podemos traducir estas construcciones en MVL en una forma prescrita y tener un impacto mínimo en el MVL y procesador central. Se debe observar que la traducción entre RES-almacén y las tablas del almacén no son necesariamente una traducción idéntica. Por ejemplo, en sistemas de programa de respaldo (tal como el programa de respaldo WinFS) que soporta UDTs, anidamientos, etc., la traducción es similar a las relaciones de objeto prescritas. La figura 15, ¡lustra un manejo del tiempo de compilación y tiempo de corrida de las vistas de mapeo. Debido al modelo de datos y especificaciones de mapeo en el MSL, tal como se ilustra a través de los números 1501, 1502 y 1503, primero generamos los RESs y números correspondientes 1521, 1522 y 1523 de las construcciones no relaciónales 1511, 1512, 1513 y las traducciones prescritas entre estas construcciones y las RESs, es decir, los mapeos N-MVL. Posteriormente, generamos la Vista de Mapeo de Solicitud y Actualización, Objeto-EDM en R-MVL y EDM-almacén en R-MVL, para mapeos no prescritos requeridos por el desarrollador - se debe observar que estas vistas de mapeo operan en el RESs utilizando el lenguaje R-MVL. En este punto, generamos las expresiones delta (expresiones de mantenimiento de vista) para las Vistas de Mapeo de Solicitud y Actualización - dichas reglas han sido desarrolladas para construcciones relaciónales. Se debe observar que las expresiones delta para QMViews son necesarias con el propósito de notificaciones. Para los mapeos N-MVL, las expresiones delta son determinadas en el tiempo de diseño por nosotros, ya que estos mapeos son prescritos, por ejemplo, cuando mapeamos una recolección de Dirección a una asociación de una-a-muchos, también diseñamos las expresiones de mantenimiento de vista correspondientes. Debido a las vistas y traducciones anteriores (N-MVL y R-MVL) podemos componerlas para obtener Vistas de Mapeo de Solicitud que pueden expresar objetos 1531 en términos de tablas en el almacén 1533, y Vistas de Mapeo de Actualización que pueden expresar tablas 1533 en términos de objetos 1531. Tal como lo muestra la figura, podemos elegir retener las vistas de mapeo, de modo que las Entidades EDM en 1532 no sean completamente eliminadas del mapeo para el tiempo de rutina - una razón posible para mantener estas vistas es permitir ciertos tipos de optimización de solicitud que toman la ventaja de las restricciones EDM. Por supuesto, esto no significa que realmente almacenemos Entidades EDM en el tiempo de corrida. La figura 16, muestra como los diferentes componentes logran el proceso de compilación de vista descrito anteriormente. Las aplicaciones invocan el API 1600. Los Generadores de Vista 1601, 1603 son responsables de tres funciones: traducir las construcciones no relaciónales en construcciones RES, y generar las Vistas Solicitud/Actualización, y generar las expresiones delta para propagar actualizaciones y notificaciones. Pueden utilizar metadatos 1602 para llevar a cabo estas funciones. El compositor de la Vista OE 1605 toma la información de Objeto y EDM y la compone, de modo que tenemos expresiones algebraicas de objetos en términos de tipos EDM; en forma similar, el Compositor de Vista ES 1606, produce expresiones algebraicas de tipos EDM en términos de tablas. Componemos estas vistas en forma adicional en el Compositor de Vista OE 1607 y obtenemos un solo conjunto de vistas en el almacén de metadatos 1608. Tal como se describió anteriormente, podemos mantener dos conjuntos de vistas para posibles oportunidades de optimización de solicitud. Finalmente, también puede operar un componente de análisis de dependencia 1604 en la salida del Generador de Vista ES para proporcionar un orden de dependencia para el almacén de metadatos 1608. Resumen de compilación de mapa En resumen, para cada especificación M de una clase, tipo EDM, o tabla, generamos los RESs correspondientes y las traducciones prescritas entre M y los RES correspondientes. Por lo tanto, generamos lo siguiente tal como se ilustra en la figura 15: 1. RES que corresponde a M - denotado como RES-CDM(M), RES-Object(M) o RES-Store (M). 2. Traducción prescrita que expresa cada especificación M en términos de relaciones RES. 3. Traducción prescrita que expresa dicha relación RES en términos de M. 4. Vistas de Mapeo de Solicitud: existen dos de dichas vistas - los objetos que expresan OE QMViews en términos de tipos EDM y QMViews que expresan tipos EDM en términos de almacén (tablas). 5. Vistas de Mapeo de Actualización: Existen dos de dichas vistas - las OE UMViews que expresan tipos EDM en términos de objetos y ES UMViews que expresan las tablas de almacén en términos de tipos EDM. 6. Para el mantenimiento incremental de actualizaciones, también generamos expresiones delta en las UMViews. Después de componer estas vistas, finalizamos con cuatro mapas. Estos mapas se almacenan en el almacén de metadatos 1608 y son referidos colectivamente como las Vistas de Mapeo Compiladas. Mapas de Solicitud: Se expresan objetos/CDN en términos de CDM/tablas. Mapas de Actualización: Se expresan tablas/CDM en términos de CDM/objetos. Expresiones Delta de Actualización: Se expresan deltas en tablas/CDM en términos de deltas en CDM/objetos. Expresiones Delta de Notificación: Se expresan deltas en objetos/CDM en términos de deltas en CDM/tablas. Orden de dependencia: Orden en el cual se deben llevar a cabo diversas operaciones de inserto, eliminación, actualización en diferentes relaciones - este orden asegura que las restricciones de la base de datos no sean violadas durante el proceso de actualización. Ejemplo de recolección A continuación mostramos brevemente las traducciones prescritas y mapeos no prescritos para el ejemplo de Persona que habíamos considerado. Presentamos tanto las vistas de mapeo de solicitud como de actualización - las expresiones de mantenimiento de la vista correspondientes se describen con mayor detalle más adelante. RESs Traducimos el OPerson en una construcción RES R_OPerson que simplemente refleja el nombre y pid; en forma similar, traducimos OAddress a R_OAddress. Para traducir la recolección de direcciones, utilizamos una asociación de uno-a-muchos R_OPerson_Address. En forma similar, para las construcciones EDM también. Los RESs para las tablas (R_SPerson, R_SAddress) son mapeos de identidad para SPerson y SAddress. Estos RESs son: Vistas de Mapeo de Solicitud Mostramos el mapeo de objeto-almacén (compuesto a través de los mapeos Object-EDM y EDM-Store). Vistas no prescritas en el espacio RES Los mapeos entre el espacio de objeto y EDM son esencialmente idénticos. Todas las tres vistas R_CPerson, R CAddress y R_CPerson_Address son simplemente proyecciones en R SPerson y RSAddress.

CREAR VISTA CREAR VISTA CREAR VISTA R CPerson (pid, nombre) R_CPerson_Address R_CAddress (aid, (pid, aid) state)AS AS AS SELECCIONAR aid, estado SELECCIONAR pid, SELECCIONAR pid, aid DE R_SAddress nombre DE R SPerson DE R SAddress Traducción Prescrita(Objetos en términos de RES_Objects) El objeto OPerson se expresa utilizando R_OPerson, R_OAddress y ROPerson_Address realizando una unión de R OPerson Address con R OAddress y anidando el resultado.

CREAR VISTA PRESCRITA OPerson (pid, nombre, addrs)AS SELECCIONAR, pid, nombre, NEST (SELECCIONAR Address (a.aid, a state) DESDE R_OAddress a, RI_OPerson_Address pa EN CUANDO pa.pid = p.pid AND a.aid = pa.aid) R_OPerson p Vista compuesta de CPerson La expresión compuesta desde de la simplificación puede ser (se debe remarcar que tenemos una traducción de identidad entre las tablas y sus construcciones RES para este ejemplo).

CREAR VISTA OPerson (pid, nombre, addrs)AS SELECCIONAR, pid, nombre, NEST (SELECCIONAR Address (a.aid, a state) DESDE SAddress a EN CUANDO a.pid = p.pid) SPerson p La vista final manifiesta lo que esperábamos obtener utilizando un método de mapeo "directo". Un beneficio del método RES aparece cuando vemos en expresiones delta para el trayecto de actualización, y también en el trayecto de notificación en cuando necesitamos expresiones delta para las Vistas de Mapeo de Solicitud. Vistas de mapeo de actualización Vistas no prescritas en espacio RES Space El UMViews para R_SPerson es simplemente una proyección en R CPerson, en tanto que R_SAddress se construye uniendo R_CAddress con la asociación uno-a-muchos -R_CPerson_Address. El mapeo entre el espacio de CDM y objeto es identidad.

CREAR VISTA R_SPerson (P¡d, CREAR VISTA R_SAddress (aid, pid, nombre) AS state) AS SELECCIONAR pid, nombre SELECCIONAR aid, pid, state DE R_CPerson CUANDO R_CPerson_Address.aid = R CAddress aid Traducción prescrita (Objetos RES en términos de Objetos) Necesitamos traducir los objetos en RESs de modo que las actualizaciones puedan ser impulsadas desde el espacio de objeto hasta el espacio de RES. La traducción prescrita para R_OPerson es una proyección simple, en tanto que las traducciones para R_OAddress y R_OPerson_Address se logran llevando a cabo una unión entre una persona y sus direcciones. Esta es una "unión de señalización" o una "unión de navegación".

Vistas de Mapeo de Actualización Compuesta Compusimos las anteriores vistas (y con cierta simplificación) para obtener las siguientes vistas de mapeo de actualización compuestas: CREAR VISTA SPerson (pid, nombre) I CREAR VISTA SAddress (aid, pid, AS state) AS SELECCIONAR pid, nombre SELECCIONAR a.aid, p.pid, a.state DE R CPerson | DE OPerson p, p.addrs.a Por lo tanto, la tabla SPerson puede ser expresada como una proyección simple en OPerson, en tanto que SAddress se obtiene uniendo OPerson con sus direcciones. Validación de Vista Una propiedad importante que las vistas generadas necesitan satisfacer, es que deben "hacer el recorrido de ida y vuelta", es decir, evitar cualquier pérdida de información, debemos asegurar que cuando una Entidad/Objeto que es guardada y posteriormente recuperada, no exista pérdida de información. En otras palabras, deseamos asegurar para todas las entidades/objetos D: D = QMViews (UMView(D)) Nuestro algoritmo de generación de vista asegura esta propiedad. Si esta propiedad es cierta, también decimos que el "el recorrido de ida y vuelta" de vistas de solicitud de actualización" o son bidireccionales. A continuación demostramos esta propiedad para el ejemplo de persona-dirección. Por simplicidad, nos enfocamos en el round-tripping en el espacio RES. Validación de R_OPerson Substituyendo SPerson en la vista de solicitud por OPerson, obtenemos: R_OPerson(pid, nombre, edad) = SELECCIONAR pid, nombre, edad DE (SELECCIONAR pid, nombre), edad DE R_SPerson) Simplificamos para obtener R_OPerson (pid, nombre, edad) = SELECCIONAR pid, nombre, edad DE R SPerson Esto es equivalente a SELECCIONAR * DE Persona. Validación para OPerson_Address Para R_OPerson_Address, es ligeramente más complicado. Tenemos: R_OPerson_Address (pid, aid) = SELECCIONAR pid, aid DE R SAddress Substituyendo por R_SAddress, obtenemos: R_OPerson_Address (pid, aid) = SELECCIONAR pid, aid DE (SELECCIONAR aid, pid, state DE R_OPerson_Address pa, R_OAddress a CUANDO pa.aid = a.aid) Esto se obtiene simplificado como: Para mostrar que lo anterior es realmente SELECCIONAR*DE R_OPerson_Address necesitamos tener una dependencia de clave extraña R_OPerson_Address.aid ? R_OAddress.aid. Si esta dependencia no se mantiene, no podemos recorrer de ida o vuelta. Esto se mantiene ya que el rango de dirección de propiedad valuada por conjuntos R_OAddress. Esta restricción de clave extraña puede ser manifestada de dos maneras: 1. R_OPerson_Address.aid c R_OAddress.aid 2. a¡d, pid (R_OPerson_Address °°aid R_OAddress = R_OPerson_Address Substituyendo esta descripción en la expresión anterior obtenemos: R_OPerson_Address (pid, aid) = SELECCIONAR pid^ aid DE R_OPerson_Address Validación para Dirección R_OAddress se determina como: R_ OAddress (aid, state) = SELECCIONAR aid, state DE R__SAddress Substituyendo por R_SAddress obtenemos, R_OAddress (aid, state) = SELECCIONAR aid, state DE (SELECCIONAR aid, pid, state DE R_OPerson_Address pa, R_OAddress a CUANDO pa.aid = a.aid) Esto se puede reexpresar como: I R_OAddress (aid, state) = SELECCIONAR aid, state DE R_OPerson_Address pa, R_OAddress a CUANDO pa.aid = a.aid Aquí, la unión con R_OPerson_Address es redundante si la dependencia de la clave extraña R_OAddress.aid ? R_OPerson_Address.aid se mantiene. Esta dependencia se mantiene únicamente si R_OAddress es existencialmente dependiente de R_OPerson (por ejemplo addrs es una composición). Si esto no es cierto, entonces nuestras vistas no pueden recorrer de ida y vuelta. Por lo tanto obtenemos una restricción "aid. state (R_OAddress °°a¡d R_OPerson_Address = R_OAddress Por lo tanto, obtenemos la siguiente expresión: ~R~OAddress (aid, state) = SELECCIONAR aid, state DE R OAddress TRADUCCIÓ DE SOLICITUD Traductor de solicitud El traductor de solicitud EDP (EQT) es responsable de traducir las solicitudes del espacio objeto/EDM en un espacio del proveedor, utilizando el mapeo de metadatos. Las solicitudes del usuario pueden ser expresadas en una variedad de sintaxis, por ejemplo, eSQL, C# Sequences, VB SQL, etc. La arquitectura EQT se muestra en la figura 17. Describimos los diferentes componentes del EQT. El analizador 1711 lleva a cabo el análisis de sintaxis, analizando una solicitud del usuario expresada en una de varias formas - incluyendo eSQL, Solicitud Integrada por Lenguaje (LINQ), C#Sequences y VB Sql.Any cualquier errores de sintaxis son detectados y señalados en este momento. Para LINQ, el análisis de sintaxis (y el análisis semántico) se integra con las fases de análisis de sintaxis del lenguaje (C#, VB, etc.) por si mismo. Para eSQL, la fase de análisis de sintaxis es una parte del procesador de solicitud. Normalmente existe un analizador de sintaxis por lenguaje. El resultado de la fase de análisis de sintaxis es un árbol de análisis. Este árbol posteriormente es alimentado en la fase de Análisis de Semántica 1712. El Componente de Enlazador de Parámetro y Analizador Semántico 1712 maneja parámetros en las solicitudes del usuario. Este módulo rastrea los tipos de datos y valores de parámetros en la solicitud. La fase de Análisis Semántico valida semánticamente el árbol de análisis producido por las fases de análisis de sintaxis 1711. Cualquiera parámetros en la solicitud deben de estar ya enlazados en este momento, es decir, sus tipos de datos deben ser conocidos. Cualesquiera errores semánticos son detectados y señalados aquí; si tiene éxito, el resultado de esta fase es un árbol de semántica. Se debe observar que para LINQ, tal como se mencionó anteriormente, la fase de análisis de semántica se integra con la fase de análisis de semántica del propio lenguaje. Existe normalmente un analizador de semántica por lenguaje, ya que existe un árbol de sintaxis por lenguaje. La fase de análisis de semántica comprende en forma lógica lo siguiente: 1. Resolución de nombre: Todos los nombres en la solicitud son resueltos en este momento. Esto incluye referencias a extensiones, tipos, propiedades de tipos, métodos de tipos, etc. Como un efecto secundario, los tipos de datos de dichas expresiones también son inferidos. Esta subíase interactúa con el componente de metadatos. 2. Previsión e inferencia de tipo: Las expresiones en la solicitud son revisadas por tipo, y los tipos de resultado son inferidos. 3. Validación: Aquí ocurren otros tipos de validación. Por ejemplo, en un procesador SQL, si un bloque de solicitud contiene un inciso group-by, esta fase puede ser utilizada para forzar la restricción de que la lista de selección puede referirse únicamente a claves group-by o funciones de agregado. El resultado de la fase de análisis de semántica es un árbol de semántica. En ese momento, la solicitud es considerada como válida - no deben ocurrir errores de semántica adicionales en cualquier momento posterior durante la compilación de la solicitud. La fase de algebraización 1713, toma el resultado de la fase de análisis de semántica 1712, y lo convierte en una forma más adecuada para transformaciones algebraicas. El resultado de esta fase es un árbol de operador relacional extendido lógico, árbol de algebra aka. El árbol de algebra está basado en los operadores de algebra relaciónales centrales-seleccionar, proyectar, unir, unión y extiende esto con operadores adicionales tipo nido/sin nido y pivote/sin pivote. La fase de desdoblamiento de vista 1714 del traductor de consulta sustituye, posiblemente en forma de recurso, las expresiones QMView de cualesquier objetos referenciados en la solicitud del usuario. Al final del proceso de traducción de vista, obtenemos un árbol que describe la solicitud en términos de almacén. En el caso de la capa de objeto, el desdoblamiento de vista pudo haber sido realizado todo el tiempo para el espacio de almacén (en el caso en que tuvimos un mapeo OS optimizado almacenado en el depósito de metadatos) o el árbol de solicitud pudo haber sido transformado a la capa EDM. En el último caso, necesitamos tomar este árbol y realimentarlo al componente de Desdoblamiento de Vista con el requerimiento de que los conceptos EDM ahora sean traducidos en conceptos de almacén. El componente de Transformación/Simplificación 1715 puede ser el proveedor específico 1730, o en una modalidad alternativa, puede ser un componente EDP-genérico que puede ser apalancado a través de varios proveedores. Existen unas cuantas razones para llevar a cabo transformaciones en el árbol de solicitud: 1. Operador que impulsa el almacenamiento: El EQT impulsa a los operadores complejos (por ejemplo unión, filtro, agregado) al almacén. De otra forma, dichas operaciones pueden tener que se implementadas en el EDP. La capa de materialización de valor del EDP únicamente lleva a cabo operaciones de "compensación no relaciona!", tal como anidado. Si no tuviéramos la capacidad de impulsar un operador X debajo de los nodos de materialización de valor en el árbol de solicitud y la capa de materialización de valor no puede llevar a cabo la operación X, declaramos la solicitud como ilegal. Por ejemplo, si la solicitud tiene una operación de agregación que no puede ser impulsada al proveedor, declararemos la solicitud como ilegal, ya que la capa de materialización del valor no lleve a cabo ninguna agregación. Desempeño mejorado: La complejidad reducida de la solicitud es importante, y deseamos evitar el envío de solicitudes gigantes al almacén del programa de soporte. Por ejemplo, algunas de las solicitudes corrientes en WinFS, son muy complejas y toman una gran cantidad de tiempo en ejecutarse (las solicitudes descritas a mano correspondientes son más rápidas en un orden de magnitud). Depuración de errores mejorada: Las solicitudes más simples también pueden hacer más fácil al desarrollador del la depuración de errores. El modelo de transformación/simplificación 1715 puede transformar algunos o todos los árboles de álgebra que representan la solicitud en subárboles equivalentes. Se debe observar que estas transformaciones a base de heurística son lógicas, es decir, no se realizan utilizando un modelo de costo. El tipo de transformaciones lógicas puede incluir los siguientes servicios específicos del proveedor de ejemplo: Allanamiento de sub-solicitud (sub-solicitudes de vista y anidadas) Eliminación de unión Eliminación y consolidación de predicado Empuje de predicado Eliminación de su b-expresión común Reducción de proyección Transformaciones Outer Join ? Inner Join Eliminar correlación izquierda Este módulo de Generación SQL 1731 es parte del componente de proveedor 1730, ya que el SQL generado es específico del proveedor. Después de la simplificación, el árbol de algebra se pasa al proveedor quien puede llevar a cabo en forma adicional transformaciones específicas del proveedor o simplificaciones antes de generar el SQL adecuado. Después de que se ejecuta la solicitud en el servidor, los resultados son enviados al cliente EDP. El proveedor 1730 expone DataReaders que puede ser utilizada por una aplicación para obtener los resultados como entidades EDM. El servicio de materialización de valor 1741 puede tomar estos lectores y convertirlos en entidades EDM relevantes (en la forma de nuevos DataReaders). Estas entidades pueden ser consumidas por una aplicación o los nuevos DataReaders pueden ser pasados a un servicio de materialización de objeto superior. El EQT 1700 representa materialización como un operador en el árbol de solicitud. Esto permite que el trayecto de traducción de solicitud regular produzca objetos en el espacio EDM, lo cual posteriormente puede ser directamente alimentado de los usuarios, en lugar de requerir operaciones fuera de banda especiales para llevar a cabo la materialización real. Esto también permite que varias optimizaciones tipo retomar objetos parciales, carga ávida, etc. sean llevados a cabo en las solicitudes del usuario. Ejemplo de solicitud Considerar el ejemplo Person-Add ress que hemos desarrollado. Se supone que el usuario desea correr la siguiente solicitud - encontrar todas las personas en WA.

Podemos describir esta solicitud en pseudos-CSQL como: SELECCIONAR x.nombre.DE OPerson x, x.addrs y CUANDO y state = "WA" Si realizamos el desdoblamiento de vista utilizando la Vista de Solicitud para Persona en este punto, obtenemos: SELECCIONAR x.nombre DE (SELECCIONAR pid; nombre, NEST(SELECCIONAR OAddress (a.aid, a.state) DE SAddress a.cuando a. pid = p.pid) DE SPerson p) as x, x.addrs y CUANDO y state = "WA" Esta solicitud puede ser simplificada antes de enviar servidor backend: SELECCIONAR p.nombre DE (SELECCIONAR pid; nombre, NEST(SELECCIONAR OAddress (a.aid, a.state) DE SAddress a.cuando a. pid = p.pid) DE SPerson p) as x, x.addrs y CUANDO y state = "WA" SELECCIONAR p.nombre DE SPerson p, SAddress a CUANDO p.pid = a.pid Metadatos El EQT requiere varias piezas de metadatos durante la compilación y ejecución de una solicitud. Estos metadatos incluyen: Metadatos de aplicación-espacio: Información con respecto a Extensiones/Recolecciones, Tipos, Propiedades de Tipo, Métodos de Tipo requerida durante el análisis de semántica para validar las solicitudes del usuario. Metadatos de esquema-espacio: Información con respecto a Recolecciones de Entidad, Tipos CDM y propiedades requeridas durante la compilación de vista. Información con respecto a relaciones entre entidades y restricciones en entidades para transformaciones. Metadatos de almacenamiento-espacio: Tal como se describió anteriormente. Mapeos de Aplicación -> Esquema: el árbol del Operador de Lógica que representa la definición de vista requerida para la Expansión de Vista. Mapeos de Esquema -> Almacenamiento: Tal como se describió anteriormente. Trayecto de Reporte de Error Los errores en varias etapas del procesamiento de la solicitud deben ser reportados en términos comprensibles para el usuario. Pueden ocurrir varios errores de tiempo de compilación y ejecución durante el procesamiento de solicitud. Los errores durante el análisis de sintaxis y semántica en su mayoría son de espacio de aplicación, y requieren muy poco manejo especial. Los errores durante las transformaciones son en su mayoría errores de recurso (fuera de memoria, etc.), y necesitan cierto manejo especial. Los errores durante la generación de código y ejecución de la solicitud subsecuente pueden necesitar ser procesados en forma adecuada. Un desafío clave en el reporte de errores, es mapear los errores de tiempo de corrida que ocurren en niveles de abstracción inferiores para errores que son significativos en el nivel de aplicación. Esto significa que necesitamos procesar errores de nivel inferior a través de los mapeos de almacenamiento, conceptuales y de aplicación. Ejemplo de Solicitud Nuestra solicitud OO de muestra, retoma el nombre de todas las personas que tienen una dirección en Washington: SELECCIONAR p.name DE OPerson p: p: addrs.as.a CUANDO a. state = WA Paso 1: Conversión a términos relaciónales Esta solicitud puede ser convertida en la solicitud puramente relacional expresada en términos de R_OPErson, R_OPerson_Address, y R_Oaddress. Esencialmente, expandimos las diversas propiedades de navegación ("." Expresiones) en la expresión de unión si es necesario. SELECCIONAR p.name DE R_OPerson p, R_OPerson_Address pa, R_OAddress a CUANDO p.pid = pa.pid AND pa.aid = a.aid AND a. state = WA' Se debe observar que la solicitud aún está en el dominio de objeto y en términos de extensiones del objeto. Paso 2: Desdoblamiento de Vista: Conversión a Espacio de Almacenamiento A continuación desdoblamos la vista para convertir la solicitud en SQL: SELECCIONAR p.name DE (SELECCIONAR pid, ñame, age DE SPerson) p, (SELECCIONAR pid, aid DE SAddress) pa; (SELECCIONAR aid, state, DE SAddress) a CUANDO p.pid = pa-pid Y pa.aid = a. aid Y a. state = WA' Paso 3: Simplificación de Solicitud A continuación aplicamos una serie de transformaciones lógicas para simplificar esta solicitud. SELECCIONAR p.name DE SPerson p, SAddress pa, SAddress a CUANDO p.pid = pa.pid Y pa.aid = a. aid Y a. state = WA Ahora, podemos eliminar la auto-unión redundante en la clave primaria de SAddress (aid) y obtener: . SELECCIONAR p.name DE SPerson p, SAddress a CUANDO p.pid = a. pid Y a. state = WA Todo lo anterior es muy sencillo. Ahora tenemos una solicitud que puede ser enviada a través del Servidor SQL. PROCESAMIENTO DE TIEMPO-COMPILACIÓN PARA ACTUALIZACIONES El EDP permite que las aplicaciones creen objetos nuevos, las actualicen, las eliminen y posteriormente almacenen estos cambios en forma persistente. El componente de mapeo OR necesita asegurar que estos cambios son traducidos correctamente en cambios de almacén del programa de respaldo. Como se describe anteriormente, utilizamos las Vistas de Mapeo de Actualización que declaran una tabla en términos de objetos. Al utilizar dichas vistas, hemos reducido esencialmente el problema de actualización de programación a un problema de mantenimiento de vista meterializado, en cuando los cambios a las relaciones base necesitan ser propagadas para las vistas; en el caso de UMViews, las "relaciones base" son objetos y las "vistas" son las tablas. Al modelar el problema en esta forma, podemos apalancar el conocimiento de la tecnología de mantenimiento de vista que ha sido desarrollado en el mundo de las bases de datos relaciónales. Generación de Vista de Mapeo de Actualización Como en el caso de la solicitud, se lleva a cabo un lote de trabajo de mapeo de actualizaciones en el tiempo de compilación. Junto con los Esquemas Expresados en forma Relacional para las clases, los tipos EDM, y las tablas, generamos las traducciones pre-escritas de estos tipos y las construcciones RES correspondientes. También generamos las Vistas de Mapeo de Actualización entre las construcciones RES de clases y los Tipos EDM, y las construcciones RES de los tipos EDM y las tablas del almacén.

Nos permitimos comprender estas UMViews con ayuda del ejemplo de Persona-Dirección que hemos desarrollado. Remarcamos las construcciones RES para objetos (R_OPerson, R_OAddress, R_OPerson_Address) que fueron construidas. Vistas de Mapeo de Actualización (RES de tablas en términos de RES de objetos) La UMView para R_Operson es simplemente una proyección de R_SPerson en tanto que R_SAddress se construye uniendo R_OAddress con la asociación de uno a muchos table-R_OPerson_Address. CREAR VISTA R_SPerson (pid.name) AS SELECCIONAR pid.name, DE R_OPerson CREAR VISTA R_SAddress(aid, pid, state) AS SELECCIONAR aid, pid, state DE R_OPerson_Address pa, R_OAddress a CUANDO pa-aid = a. aid Traducciones prescritas (RES en términos de objetos) Necesitamos traducir los objetos en RESs, de modo que las actualizaciones puedan ser empujadas del espacio de objeto al espacio RES. Utilizamos la función "o2r" para traducir la dirección de la memoria virtual de un objeto para las claves pid y aid - en la implementación podemos obtener simplemente las claves del estado de sombra del objeto. La traducción prescrita para R_OPerson en una proyección simple en tanto que las traducciones para R_OAddress y R_0 Person_Add ress se logran llevando a cabo una unión entre una persona y sus direcciones.

Vistas de Mapeo de Actualización Compuestas Compusimos las vistas anteriores (y con cierta simplificación) para obtener las siguientes vistas de mapeo de actualización compuestas: Por lo tanto, la tabla SPerson puede ser expresada como una proyección simple en OPerson, en tanto que SAddress se obtiene uniendo OPerson con sus direcciones. Generación de Expresión Delta Cuando una aplicación solicita que sus cambios de objetos sean guardados en el respaldo, las modalidades pueden trasladar estos cambios al almacén de respaldo, es decir, pueden generar expresiones delta para las tablas (vistas) en términos de las expresiones delta de los objetos (relaciones base). Esta es el área en donde la fragmentación del proceso de generación/compilación de vista en las construcciones RES, realmente es una ayuda. Las expresiones delta para los mapeos no prescritos pueden ser generadas con relativa facilidad, ya que estos mapeos están en el especio relacional (RESs son puramente relaciónales) y un lote de trabajo en las bases de datos relaciónales han sido elaboradas para lograr esta meta. Por ejemplo, en la literatura de las bases de datos, se han desarrollado reglas de expresión delta para vistas que se expresan en términos de operadores relaciónales tal como selecciones, proyecciones, semi-uniones internas o externas, uniones, interacciones y diferencias. Para las construcciones no relaciónales, todo lo que necesitamos hacer es diseñar expresiones delta prescritas que convierten las construcciones no relaciónales hacia/desde el espacio RES. Se comprenderán las expresiones delta con nuestro ejemplo de Persona. Considerar el caso en donde se expresa una construcción RES (por ejemplo, R_SAddress) como una unión de dos recolecciones de objeto (R_OAddress y R_OPerson_Address). La expresión delta para dicha vista puede ser obtenida utilizando las siguientes reglas (suponer que la vista de unión es V = R JOIN S): '_·' '¦ ¦¦·&· '¦ ¦>'¦ S] „, U .ON [d(S) JOIÑ -R.] ; ·:.:¦·¦ ' _ .

En esta expresión, i(X) y d(X) denotan registros para la relación o vista X, y Rnew denota el nuevo valor de las relaciones de base R después de que se han aplicado todas sus actualizaciones. Por lo tanto, para facilitar las actualizaciones en tiempo de corrida, una modalidad de ejemplo puede ser generar primero las siguientes expresiones delta en el tiempo-compilación: 1. Expresiones de cambio delta prescritas 1803 para relaciones RES 1811 en términos de expresiones de cambio delta para grupos de recolecciones de objeto actualizadas 1801, por ejemplo, i(R_OPerson) en términos de ¡(OPerson). 2. Expresiones de cambio delta prescritas 1804 para tablas 1802 en términos de expresiones de cambio delta para relaciones RES 1812, por ejemplo, ¡(SPerson) en términos de i(R_SPerson). 3. Expresiones delta 1813 para relaciones RES de tablas expresadas en términos de expresiones delta de relaciones RES de objetos, por ejemplo, i(R_SPerson) en términos de i(R_OPerson). Podemos componer (1), (2) y (3) para obtener una expresión delta 1820 para las tablas 1822 (por ejemplo, SPerson) en términos de expresiones delta para objetos 1821 (por ejemplo, OPerson). Esta composición se ilustra en la figura 18. Por lo tanto, en el caso de las solicitudes, en el tiempo de compilación, tenemos ahora una traducción directa de objetos a tablas. En el caso de actualizaciones, tenemos realmente apalancada la fragmentación RES para generar las expresiones delta (para las QMViews, esta ventaja es aplicable para notificaciones). Se debe observar que no necesitan ser expresiones delta para actualizaciones - como lo observaremos más adelante, las actualizaciones de modelo pueden ser modeladas colocándolas en el conjunto de insertar y eliminar; un paso de procesamiento posterior las convierte nuevamente a actualizaciones antes de que los cambios sean realmente aplicados a la base de datos. Una razón para este método, es que el trabajo existente en el mantenimiento de vista incremental normalmente no tiene expresiones delta para actualizaciones. Como alternativa, son factibles modalidades más complejas en las cuales dichas expresiones son desarrolladas. Después de que se haya llevado a cabo la composición de vista, las expresiones delta para las tablas puede ser puramente en términos de las recolecciones de objeto y los conjuntos de insertar y eliminar de los objetos, por ejemplo, i(SPerson) en términos de OPerson, ¡(OPerson), y d(OPerson). Algunas de estas expresiones delta pueden necesitar que se computaricen recolecciones de objeto, por ejemplo, ¡(OPerson) necesita EPerson para su cómputo. Sin embargo, la recolección completa puede no ser cacheada en el cliente EDP (o podemos no desear correr la operación en el valor último y más consistente de la recolección). Para tener este problema, desdoblamos las recolecciones de objeto utilizando las Vistas de Mapeo de Solicitud correspondientes, por ejemplo, utilizamos la QMView para OPerson y se expresa en términos de SPerson y si es necesario, otras relaciones. Por lo tanto, en una modalidad, al final del proceso de compilación, todas las expresiones delta para SPerson son expresadas en términos de i(OPerson), d(OPerson), y la propia relación SPerson - en el tiempo de corrida, debido a que los conjuntos de insertar y eliminar de OPerson, ahora podemos generar las expresiones SQL relevantes que pueden ser ejecutadas en el servidor. En resumen, debido a QMViews y UMViews entre las construcciones RES de las tablas y objetos, y las traducciones prescritas entre estas construcciones y las tablas/objetos, se pueden llevar a cabo los siguientes pasos de ejemplo: 1. Generar las expresiones delta mencionados anteriormente en los pasos 1, 2 y 3 anteriores. 2. Componer estas expresiones de modo que tengamos expresiones delta para las tablas (SPerson) en términos de expresiones delta de los objetos (OPerson) y las propias recolecciones de objeto. 3. Desdoblar las recolecciones de objeto utilizando sus QMViews para obtener expresiones delta para las tablas (SPerson) en términos de expresiones delta de los objetos y las propias tablas, es decir, se eliminan las recolecciones de objeto. Puede haber casos especiales que permitan a las modalidades evitar este desdoblamiento o saber que la recolección completa está cacheada en el cliente. 4. Simplificar/optimizar la expresión de modo que se reduzca el trabajo de tiempo de corrida. Además de las implementaciones específicas mencionadas en forma explícita en la presente invención, los expertos en la técnica podrán apreciar otros aspectos e implementaciones a partir de la consideración de la especificación aquí descrita. Se pretende que la especificación y las implementaciones ilustradas sean consideradas únicamente de ejemplo, con un alcance y espíritu real de las siguientes reivindicaciones.

Claims (20)

1. REIVINDICACIONES 1. Un método para proporcionar servicios de datos a una aplicación, caracterizado porque comprende: generar una vista de solicitud 1302 que expresa al menos una parte de un esquema de aplicación asociado con la aplicación en términos del esquema de la base de datos asociado con una base de datos; generar una vista de actualización 1412 que expresa al menos una parte del esquema de la base de datos en términos del esquema de aplicación; utilizar la vista de solicitud para la solicitud de la base de datos 1303 a nombre de la aplicación de solicitud; utilizar la vista de actualización para actualizar la base de datos 1414 a nombre de la aplicación de solicitud.
2. 2. El método tal como se describe en la reivindicación 1, caracterizado porque comprende además recibir 1411, de la aplicación de solicitud, un objeto en un lenguaje de programación, comprendiendo el objeto en el lenguaje de programación datos para utilizarse en la actualización de la base de datos.
3. 3. El método tal como se describe en la reivindicación 1, caracterizado porque comprende además recibir 1411, de la aplicación de solicitud, una instrucción de crear, insertar, actualizar o eliminar, comprendiendo la instrucción de crear, insertar, actualizar o eliminar datos para utilizarse en la actualización de la base de datos.
4. 4. El método tal como se describe en la reivindicación 1, caracterizado porque comprende además recibir 1411, de la aplicación de solicitud, una expresión en un Lenguaje de Manipulación de Datos (DML), comprendiendo la expresión datos para utilizarse en la actualización de la base de datos.
5. 5. El método tal como se describe en la reivindicación 1, caracterizado porque el uso de la vista de actualización para computarizar una actualización para la base de datos, comprende aplicar un algoritmo de mantenimiento de vista a la vista de actualización.
6. 6. El método tal como se describe en la reivindicación 3, caracterizado porque la aplicación de un algoritmo de mantenimiento de vista a la vista de actualización produce una expresión delta para dicha vista de actualización, y comprende además utilizar un desdoblamiento de vista 1715 para combinar la expresión delta con una vista de solicitud.
7. 7. El método tal como se describe en la reivindicación 1, caracterizado porque la utilización de la vista de actualización para computarizar una actualización a la base de datos, comprende aplicar un algoritmo de mantenimiento de vista a los datos recibidos para utilizarse en la actualización de la base de datos.
8. 8. El método tal como se describe en la reivindicación 1, caracterizado porque el esquema de aplicación soporta clases, relaciones, herencias, agregación y tipos complejos.
9. 9. El método tal como se describe en la reivindicación 1, caracterizado porque la vista de actualización se genera utilizando un mapeo que correlaciona el esquema de aplicación con el esquema de la base de datos.
10. 10. El método tal como se describe en la reivindicación 9, caracterizado porque la vista de solicitud y la vista de actualización se generan utilizando el mapeo.
11. 11. Un sistema de acceso de datos para proporcionar servicios de datos a una aplicación, caracterizado porque comprende: un componente 110 para generar una vista de solicitud que expresa al menos una parte del esquema de aplicación asociado con la aplicación en términos del esquema de la base de datos asociado con una base de datos; un componente 110 para generar una vista de actualización que expresa al menos una parte del esquema de la base de datos en términos del esquema de aplicación; un componente 113 para utilizar la vista de solicitud para solicitar la base de datos a nombre de la aplicación de solicitud; un componente 113 para utilizar la vista de actualización para actualizar la base de datos a nombre de la aplicación de solicitud.
12. 12. La arquitectura de acceso de datos tal como se describe en la reivindicación 11, caracterizada porque comprende además un componente 113 para recibir, de la aplicación de solicitud, un objeto en un lenguaje de programación, comprendiendo el objeto en un lenguaje de programación datos para utilizarse en la actualización de la base de datos.
13. 13. La arquitectura de acceso de datos tal como se describe en la reivindicación 11, caracterizada porque comprende además un componente 113 para recibir, de la aplicación de solicitud, una instrucción de crear, insertar, actualizar o eliminar, comprendiendo la instrucción de crear, insertar, actualizar o eliminar datos para utilizarse en la actualización de la base de datos.
14. 14. La arquitectura de acceso de datos tal como se describe en la reivindicación 11, caracterizada porque comprende además un componente 113 para recibir, de la aplicación de solicitud, una expresión en un Lenguaje de Manipulación de Datos (DML), la expresión que comprende datos para utilizarse en la actualización de la base de datos.
15. 15. La arquitectura de acceso de datos tal como se describe en la reivindicación 11, caracterizada porque el componente 113 para utilizar la vista de actualización para computarizar una actualización a la base de datos, aplica un algoritmo de mantenimiento de vista a la vista de actualización.
16. 16. La arquitectura de acceso de datos tal como se describe en la reivindicación 15, caracterizada porque la aplicación de un algoritmo de mantenimiento de vista a la vista de actualización produce una expresión delta para dicha vista de actualización, y comprende además un componente 113 para utilizar el desdoblamiento de vista para combinar la expresión delta con una vista de solicitud.
17. 17. La arquitectura de acceso de datos tal como se describe en la reivindicación 11, caracterizada porque el componente 113 para utilizar la vista de actualización para computarizar una actualización a la base de datos, aplica un algoritmo de mantenimiento de vista a los datos recibidos para utilizarse en la actualización de la base de datos.
18. 18. La arquitectura de acceso de datos tal como se describe en la reivindicación 11, caracterizada porque el esquema de aplicación soporta clases, relaciones, herencias, agregación y tipos complejos.
19. 19. La arquitectura de acceso de datos tal como se describe en la reivindicación 11, caracterizada porque comprende además un componente 114 para generar un mapeo que correlaciona el esquema de aplicación con el esquema de la base de datos.
20. 20. La arquitectura de acceso de datos tal como se describe en la reivindicación 19, caracterizada porque la vista de solicitud y la vista de actualización se generan utilizando el mapeo.