MX2008011649A

MX2008011649A - Lenguaje de solicitud extensible con soporte para tipos con alto contenido de datos.

Info

Publication number: MX2008011649A
Application number: MX2008011649A
Authority: MX
Inventors: Subramanian Muralidhar; Stephen Frederick Stark; Sean B House; Simon Cavanaugh; Fabio Mereles F Valbuena; Ramesh Nagarajan
Original assignee: Microsoft Corp
Priority date: 2006-03-20
Filing date: 2007-01-16
Publication date: 2008-09-22
Also published as: RU2434276C2; AU2007227766A1; RU2008137657A; US20070219976A1; CA2642934A1; EP2013775A4; CN101427249A; CA2642934C; JP2011154707A; US7797304B2; AU2007227766B2; EP2013775A1; BRPI0708827A2; JP2009530735A; WO2007108858A1; CN101427249B; KR20080106266A

Abstract

Se proporciona un lenguaje de solicitud con soporte para tipos de datos pesados. Un sistema puede comprender una aplicación configurada para generar solicitudes de acuerdo con el lenguaje de solicitud. También se proporciona una plataforma para manejar solicitudes que son generadas de acuerdo con el lenguaje de solicitud proporcionado. La plataforma comprende generalmente una capa de servicio de objeto, una capa de proveedor de mapa, y una capa de puente que puede hacer interfase finalmente con una variedad de bases de datos comercialmente disponibles.

Description

LENGUAJE DE SOLICITUD EXTENSIBLE CON SOPORTE PARA TIPOS CON ALTO CONTENIDO DE DATOS Referencia Cruzada con Solicitudes Relacionadas La presente solicitud reclama la prioridad de la Solicitud Provisional Norteamericana No. 60/784,510, presentada el 20 de Marzo del 2006. Antecedentes de la Invención Los datos se han vuelto un elemento valioso e importante en casi cada aplicación, si es por ejemplo, una aplicación de Línea de Negocios (LOB) que busca productos y genera órdenes o una aplicación de Administración de Información Personal (PIM) que programa una reunión entre personas. Las aplicaciones se han vuelto cada vez más centradas en datos -planean una parte significativa de su diseño - y experimentan tiempo de corrida alrededor de la solicitud, manipulación y presentación de datos. Muchas de estas aplicaciones tratan con datos los cuales tienen alto contenido de semántica, tipo de integridad estructural, restricciones de datos, relaciones entre datos etc. Las aplicaciones en la actualidad necesitan una gran cantidad de esfuerzo para elaborar códigos de procedimientos para conservar la semántica de los datos. Se debe considerar, por ejemplo, una aplicación LOB. Normalmente, dicha aplicación trata con Clientes, Órdenes, Líneas de Orden, Proveedores, Productos, Empleados, Envíos, Facturas, etc. Cada una de estas nociones representa un tipo separado con alto contenido de datos con una estructura específica. Por ejemplo, el tipo de Cliente tiene aspectos tipo ID del Cliente (Customerl D), Nombre de la Compañía, Nombre del Contacto y Dirección; el tipo de Orden tiene aspectos tipo ID (OrderID) de la Orden ID del Cliente (Customerl D), Fecha de la Orden (OrderDate), Líneas de Orden (OrderLines), Fecha Conveniente (DueDate), etc. Cualesquiera de los anteriores puede tener requerimientos, por ejemplo, la Dirección puede requerir un Código Postal (PostalCode), el cual cuando está dentro de los Estados Unidos, debe ser un código zip que tiene cinco caracteres de longitud, y cada carácter es un dígito entre cero y nueve. En Canadá, el Código Postal debe ser la forma "ANA NAN" en donde A es una letra y N es un número. Cuando se modelan códigos postales, por lo tanto no es suficiente especificar meramente que es una cadena de caracteres; se deben imponer restricciones adicionales en esta cadena de caracteres, para restringir el rango de posibles valores que se puedan tomar. Además, normalmente existen relaciones entre los datos. Por ejemplo, una Orden siempre puede tener un Cliente asociado con la misma; esto es una relación (Orden)-a-Una (Cliente). Los Productos y Proveedores contienen una relación de muchos-a-muchos debido a que se pueden proveer múltiples productos a través de un solo proveedor, y múltiples proveedores pueden llevar el mismo producto.

Un modelo de datos describe la estructura y semántica de, y la relación entre, las diversas piezas de datos en las que tiene interés una aplicación. Aunque los modelos y sistemas de relación han sido muy exitosos en el manejo de datos, han fallado en capturar modelos de datos de aplicación. Las aplicaciones cliente-servidor tradicionales relegan las operaciones de solicitud y persistencia en sus datos a los sistemas de base de datos. El sistema de base de datos opera en datos en la forma de filas y tablas, en tanto que la aplicación opera en los datos en términos de construcciones de lenguaje de programación de mayor nivel, tal como clases y tipos con alto contenido de datos. El desacoplamiento de impedancia en los servicios de manipulación de datos entre la aplicación y la base de datos fue tolerable en los sistemas tradicionales. Con la llegada de arquitecturas orientadas al servicio (SOA), los servidores de la aplicación y las aplicaciones de múlti-hilera, ha incrementado tremendamente la necesidad de servicios de acceso y manipulación con alto contenido de datos que estén bien integradas con los ambientes de programación y puedan operar en cualquier hilera. La mayor parte de las aplicaciones y estructuras de aplicaciones enrolan su propio modelo de datos en la parte superior de los sistemas a base de modelo de datos de relación para puentear el desacoplamiento de impedancia entre los datos y el ambiente de programación de la aplicación. Esto es debido a que la mayor parte de las aplicaciones, ya sea LOB, PIM, Information Worker u otros, requieren conceptos de modelo de datos tipo estructura de alto contenido, relaciones, comportamientos y capacidad de extensión. Estos conceptos de modelo de datos no están soportados en forma adecuada por los modelos de datos existentes, y además actualmente no existen lenguajes de solicitud adecuados para accesar a datos, si tuvieran que ser organizados de acuerdo con un modelo de datos más avanzado. Los candidatos modernos de ejemplo para un meta-modelo de datos incluyen la versión 1999 del Lenguaje de Solicitud Estructurado (SQL99), el Tiempo de Corrida de Lenguaje Común (CLR), el Lenguaje de Modelado Unificado (UML) y Definición de Esquema XML (XSD). Sin embargo, el CLR es un tiempo de corrida de programación imperativa, orientada hacia el objeto, y no tiene un modelo de datos nativo o nociones de restricciones de integridad, relaciones, o persistencia. SQL99 carece de conceptos de modelado de datos tipo relaciones, y no tiene una buena integración de lenguaje de programación. La especificación XSD no soporta conceptos tipo claves, relaciones y persistencia, y es complejo y tiene un mapeo complicado tanto para los modelos de tiempo de corrida como de base de datos de relación. El UML es demasiado general: requiere que los desarroíladores de la aplicación agreguen semánticas precisas, especialmente para persistencia.

Existe una necesidad sin cumplir en la industria de un modelo de datos y una estructura de soporte correspondiente, que proporcione un mejor acceso de aplicación a tipos con alto contenido de datos. Existe la necesidad adicional de un lenguaje de solicitud extensible con un soporte para tipos con alto contenido de datos, que pueda ser soportado por un modelo de datos. Breve Descripción de la Invención En consideración a los inconvenientes de la técnica identificados anteriormente, la presente invención proporciona un lenguaje de solicitud extensible con soporte para tipos con alto contenido de datos. Varias características de ejemplo de lenguajes de solicitud proporcionados se describen en la presente invención. Además, el sistema puede comprender una aplicación configurada para generar solicitudes de acuerdo con el lenguaje de solicitud. También se proporciona una plataforma para manejar solicitudes que son generadas de acuerdo con el lenguaje de solicitud proporcionado. La plataforma comprende generalmente una capa de servicios de objeto, una capa del proveedor de mapa, y una capa puente que finalmente puede hacer interfase con una variedad de bases de datos comercialmente disponibles. Breve Descripción de las Figuras Los sistemas y métodos para un lenguaje de solicitud extensible con un soporte para tipos con alto contenido de datos 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 soporte de aplicación para aplicaciones que accesan datos de acuerdo con los sistemas y métodos aquí proporcionados. La figura 2, son los componentes principales de una arquitectura CDP, y describe en particular la trayectoria de solicitud que puede conducir las solicitudes elaboradas utilizando un lenguaje de solicitud extensible para tipos con alto contenido de datos descritos con mayor detalle más adelante. La figura 3, ilustra un grupo de Vista (Outlook) a través de una vista de fecha similar a una vista de un grupo de amigos generado utilizando un método calculado de acuerdo con la presente invención. Descripción Detallada de la Invención Se establecen ciertos detalles específicos en la siguiente descripción y en las figuras, para proporcionar una total comprensión de varias de las modalidades de la presente invención. Sin embargo, ciertos detalles bien conocidos asociados con frecuencia con tecnologías de cómputo y software, no se establecen en la descripción que se encuentra a continuación, para evitar un obscurecimiento innecesario de las diversas modalidades de la presente invención. Además, los expertos en la técnica relevante, comprenderán que pueden practicar otras modalidades de la presente invención, sin uno o más de los detalles que se describen a continuación. Finalmente, aunque se describen varios métodos con referencia a los pasos y secuencias en la descripción que se encuentra más adelante, la descripción como tal, es para proporcionar una implementación clara de las modalidades de la presente invención, y los pasos y secuencias de pasos no deben ser tomados como requeridos para practicar la presente invención. Primero, la presente descripción proporciona un modelo de datos de ejemplo y mecanismos de soporte de datos relacionados como pueden ser utilizados en las modalidades de ejemplo de los sistemas y métodos que incorporan un lenguaje de solicitud con soporte para tipos con alto contenido de datos, tal como se describe en la presente invención. Posteriormente, se señalan y describen una variedad de características y aspectos novedosos del lenguaje de solicitud de ejemplo aquí establecido. En el Apéndice A se establece una especificación detallada de un lenguaje de solicitud de ejemplo, y las extensiones a la misma se establecen en el Apéndice B. Las implementaciones detalladas incluyen un huésped de características novedosas y útiles, tal como lo podrán apreciar los expertos en la técnica. Modelo de Datos de Ejemplo y Mecanismos de Soporte de Datos Relacionados Se puede incorporar un modelo de datos de ejemplo y mecanismos de soporte de datos relacionados en un grupo de tecnologías, tal como Objetos de Datos Activos X para una plataforma de código manejado (ADO.NET), la cual está diseñada para proporcionar un acceso consistente a fuentes de datos tales como el Servidor de Lenguaje de Solicitud Estructurado MICROSOFT® (SQL), así como fuentes de datos expuestas a través del Enlace e Incrustación de Objetos para Bases de Datos (OLE DB) y Lenguaje de Marcación Extensible (XML). Las aplicaciones del consumidor que comparten datos pueden utilizar ADO.NET para conectarse a estas fuentes de datos y recuperar, manipular y actualizar los datos. ADO.NET factoriza limpiamente el acceso a los datos de la manipulación de datos en componentes separados que pueden ser utilizados separados o en tándem. ADO.NET incluye proveedores de datos de la Estructura .NET para conectarse a una base de datos, ejecutar comandos y recuperar resultados. Dichos resultados son ya sea procesados directamente, o puestos en un objeto ADO.NET DataSet con el objeto de ser expuestos al usuario en una forma conveniente, combinada con datos de múltiples fuentes, o apartadas entre hileras. El objeto ADO.NET DataSet también puede ser utilizado en forma independiente de un proveedor de datos de Estructura .NET para manejar datos locales de la aplicación o que su fuente proviene de XML. Por lo tanto, ADO.NET proporciona funcionalidad a los desabolladores que escriben códigos manejados similares a la funcionalidad proporcionada a los desabolladores COM nativos a través de la tecnología de Objetos de Datos Activos X (ADO) la cual es familiar para los expertos en la técnica. En una modalidad, la plataforma ADO.Net puede ser extendida para proporcionar servicios de un grupo con alto contenido de datos para aplicaciones - a través de una variedad de estructuras de aplicación, tal como estructuras PIM y estructuras LOB - para accesar, manipular y manejar datos en una forma que este bien integrada con el ambiente de programación de la aplicación. La figura 1, ilustra la colocación de esta funcionalidad en una arquitectura de soporte de aplicación. La Plataforma de Datos Común (CDP) 100 puede incrementar un grupo de tecnologías tal como la plataforma ADO.Net. La Plataforma de Datos Común (CDP) 100 y las tecnologías relacionadas se describen con detalle en la Solicitud de Patente Norteamericana 11/171905. La arquitectura de soporte de aplicación de la figura 1 puede incluir, por ejemplo, una fuente de datos 110 tal como una base de datos SQL SERVER®, WinFS®, o ORACLE®; un CDP 100 que proporciona servicios con alto contendido de datos para aplicaciones y estructuras de aplicación; un grupo de servicios de estructura, por ejemplo, Estructura UAF 120 y LOB 130 que extiende y aumenta la funcionalidad CDP 100; un grupo de clases de datos, por ejemplo, 122, 132, 140 que encapsulan la funcionalidad de la estructura de datos y la lógica de aplicación general; y cualquier número de aplicaciones 150, 160, 170 que consumen la funcionalidad proporcionada por el CDP 100 y las estructuras 120, 130 y/o clases 122, 132, 140. Un modelo de datos que está soportado por CDP 100 puede comprender, por ejemplo, el Modelo de Datos de Entidad (EDM) desarrollado por MICROSOFT® Corporation of Redmond, WA. El EDM se extiende en modelos de datos de relación para acomodar múltiples estructuras de aplicación, tal como LOB, PIM, Management, etc. El EDM define una abstracción con alto contenido de objetos para datos, modelos, alto contenido de semánticas tal como relaciones de datos, minimizan el desacoplamiento entre las estructuras de aplicación y modelo de datos, soporte a ciertos comportamientos de aplicación, soporte a conceptos de relación básicos, tipos con alto contenido de sucesión y relaciones, y proporciona de manera general conceptos de modelado que capturan las semánticas de datos independiente de los almacenes de datos e hileras de despliegue. El EDM puede incorporarse en tecnologías tales como ADO.NET. La figura 2, ilustra los componentes principales de la arquitectura CDP 100, y describe en particular la trayectoria de solicitud ya que puede conducir solicitudes elaboradas utilizando el lenguaje de solicitud extensible para tipos con alto contenido de datos descritos con mayor detalle más adelante. El término "eSQL" utilizado en la presente invención para referirse a un lenguaje de solicitud extensible para tipos con alto contenido de datos, una modalidad del cual se establece con mayor detalle más adelante. La figura 2 también ¡lustra cómo una solicitud fluye a través de componentes diferentes del CDP 100. Primero, una aplicación 200 emite una solicitud contra el proveedor de servicios de objeto 210 en la forma de una solicitud eSQL. El proveedor de servicios de objeto 210 puede comprender un servidor de análisis 211 que analiza la solicitud y la convierte en un árbol canónico, y transformaciones de mapeo 212, las cuales llevan a cabo cualquier traducción de mapeo (desde un modelo de datos de aplicación hasta un EDM, tal como se proporciona en la presente invención) en el árbol canónico. El proveedor de servicios de objeto puede pasar el árbol canónico debajo del proveedor del mapa 220. El proveedor del mapa 220 encapsula la funcionalidad de mapeo de relación de objeto. Comprende transformaciones de mapeo 222 que llevan a cabo traducciones de mapeo en el árbol canónico. El proveedor de mapa pasa el árbol canónico al puente 230 para servicios de mediación. El puente 230 puede comprender un componente de servicios de compensación de solicitud 231 que factoriza el árbol canónico y lleva a cabo cualesquiera compensaciones de datos-modelo, posteriormente las pasa debajo de uno o más árboles canónicos al proveedor de almacenamiento 240. El proveedor de almacenamiento 240 traduce el árbol canónico en su dialecto nativo, por ejemplo, en un dialecto SQL, tal como SQL 2000 ó SQL 2005, o un formato de base de datos WinFS o incrustado. El proveedor de almacenamiento 240 ejecuta la solicitud, y regresa un mensaje, por ejemplo, un mensaje que puede ser formateado para ser pasado a o desde una interfase de DataReader al puente 230. El puente 230 puede comprender un servicio de ensamble de resultado/valor 232 que ensamble, si es necesario, los resultados de los DataReader potencialmente múltiple regresado por el proveedor de almacenamiento 240. El resultado de esta operación llevada a cabo por 232 es un DataReader simple en términos de espacio EDM. El proveedor de mapa 220 posteriormente simplemente regresa el DataReader del puente 230 al proveedor de servicios de objeto 210. Los servicios de objeto 210 traducen los resultados del proveedor de mapa 220 en un espacio de objeto. El proveedor de servicios de objeto 221 comprende un componente 213 que materializa opcionalmente los resultados como objetos, y deposita en la memoria caché los objetos en el mapa de identidad. Finalmente, la aplicación 200 consume el lector de datos resultante. Volviendo a los diversos aspectos salientes del EDM en forma más específica, el EDM se construye generalmente de acuerdo con cuatro conceptos centrales: tipos, instancias, entidades y relaciones. Estos conceptos pueden ser ilustrados utilizando el ejemplo de una aplicación LOB típica. Dicha aplicación trata con diferentes tipos de datos, por ejemplo, orden, cliente, líneas de orden, dirección, proveedor, producto, empleado, etc. En un uso de ejemplo de EDM, los datos de Cliente pueden ser considerados como una entidad. La entidad representa una unidad de datos de alto nivel con la que trabaja una aplicación. Cliente puede tener varios campos: CustomerID (ID de Cliente), CompanyName (Nombre de Compañía) ContactName (Nombre de Contacto), Address (Dirección) y Phone (Teléfono). Cada campo tiene un tipo, que determina la estructura de los datos que van en dicho campo. Por ejemplo, CustomerID (ID de Cliente) puede ser una cadena de caracteres de una longitud fija. Los campos CompanyName (Nombre de Compañía) y ContactName (Nombre de Contacto) también pueden ser de la cadena de caracteres del tipo. Customer (Cliente) también tiene por sí mismo un tipo; debido a que Customer (Cliente) es una entidad, este tipo puede ser referido como un tipo de entidad. Un campo de Address (Dirección) puede ser diferente a los otros campos: posee una estructura interna en la forma de otros campos, tales como City (Ciudad), State (Estado) y PostalCode (Código Postal). En EDM, el tipo de campo tal como Address (Dirección) es denominado un tipo complejo. En contraste, el tipo de CustomerID (ID de Cliente), CompanyName (Nombre de Compañía) y ContactName (Nombre de Contacto) pueden ser todos tipos simples. El campo de Phone (Teléfono) puede consistir en varios números de teléfonos, cada uno de los cuales es una cadena de caracteres. Este se denomina un tipo de recolección. El tipo específica la estructura de datos y ciertas restricciones en los valores. Los datos reales se almacenan en instancias de estos tipos. Cualquier persona familiarizada con programación orientada por el objeto, podrá esposar la analogía obvia; tipos e instancias son similares a clases y objetos, respectivamente. Tanto Customer (Cliente) como Address (Dirección) son similares en el sentido en que ambos tienen estructura interna: están compuestos de múltiples campos. Aunque semántica y operacionalmente, un Customer (Cliente) es diferente a un Address (Dirección). Customer (Cliente) actúa como la unidad para la solicitud, operaciones de cambio de datos, transacciones, persistencia y distribución. Un Address (Dirección), por otra parte siempre permanece dentro de Customer (Cliente) y no puede ser referido a, o accionado en forma independiente. En el EDM, denominamos dichas unidades de alto nivel como entidades. Todos los otros datos se consideran como en línea con las entidades. Ahora se deben considerar datos de Order (Orden) de ejemplo. Las reglas de negocios pueden requerir que cada orden tenga un cliente correspondiente. Esto se modela a través de una relación entre la entidad de Order (Orden) y la entidad de Customer (Cliente). Existen diferentes tipos de relaciones soportadas por el EDM. El que está entre Order (Orden) y Customer (Cliente) es denominado como una asociación. Las asociaciones se utilizan normalmente para modelar las relaciones pera a pera entre entidades. Cada orden puede estar compuesta de varias líneas de orden. Por ejemplo, si se ordenan cinco libros en AMAZON.COM®, entonces la información con respecto a cada libro es una línea de orden. Esto se modela como otro tipo de relación, una composición. Cada OrderLine (Línea de Orden) dentro de la composición es una entidad. Características Novedosas de Ejemplo de eSQL Posteriormente, se señalarán y describirán una variedad de características y aspectos novedosos de un lenguaje de solicitud de ejemplo. En general, el lenguaje eSQL y las extensiones al mismo, tal como se proporciona más adelante, se pueden implementar en un sistema tal como el que se describió anteriormente con referencia a las figuras 1 y 2, aunque los expertos en la técnica podrán apreciar que se pueden implementar también en otros contextos, sistemas y métodos novedosos asociados con la modalidad de ejemplo que se encuentra más adelante. El grupo de la especificación eSQL que se encuentra más adelante, comprende una variedad de características novedosas, que incluyen pero no se limitan a representar solicitudes y expresiones de Lenguaje de Manipulación de Datos (DMLs - el término "solicitud" tal como se utiliza en la presente invención, se refiere a solicitudes y DMLs) en términos de un lenguaje de modelado de datos con soporte para tipos con alto contenido de datos (un lenguaje de modelado con alto contenido de datos) tal como el EDM, árboles de comando canónicos (CTrees) que representan la forma de programación para especificar las solicitudes y DMLs en términos de un lenguaje de modelado de alto contenido de datos, funcionalidad de puente que compensa proveedores particulares manipulando las solicitudes canónicas, el uso de desdoblamiento de vista para unificar de manera elegante la estrategia de mapeo OR a través de todas las semánticas de lenguaje de modelado de datos con solicitud y actualizaciones, y la capacidad para extender el lenguaje de solicitud del centro a través de extensiones que son conducidas a partir de los meta datos. Además, los aspectos novedosos de ejemplo de las especificaciones eSQL establecidas a continuación incluyen lo siguiente. Soporte de primera clase para las recolecciones: La modalidad eSQL de ejemplo aquí proporcionada, está diseñada para ser similar a SQL, y proporciona ventajas con respecto a SQL. En general, varias versiones de SQL (SQL-92 y anterior) fueron centradas en tablas en gran medida. Las tablas se trataron como ciudadanos de primera calase, y se trataron las filas/columnas como de segunda clase. Y por supuesto, no hubo noción de las recolecciones. SQL-99 y los últimos dialectos proporcionan soporte para las recolecciones, aunque este soporte ha sido retro-ajustado en SQL-92. Witness por ejemplo, adiciones tipo pesadas tipo sin nido, aplicaciones y similares. En contraste, en una modalidad, eSQL trata con recolecciones como entidades de primera clase. Por ejemplo, las expresiones de recolección son legales en la forma de un inciso. No existe la necesidad de utilizar sintaxis sin nido. Las sub-solicitudes "dentro" y "existe" han sido generalizadas para manejar cualesquiera recolecciones - una sub-solicitud y simplemente un tipo de recolección. "e1 en e2" y "existe(e)" son las construcciones eSQL que llevan a cabo estas operaciones. Además, muchas de las operaciones (unión, intersección, excepción) operan en las recolecciones. Las uniones operan también en las recolecciones. Todo es una expresión: El estándar SQL siempre ha tenido un sistema de dos niveles - sub-solicitudes (tablas) y expresiones (filas, columnas). En una modalidad, con el objeto de proporcionar soporte de primera clase para recolecciones y recolecciones anidadas, eSQL adopta un modelo mucho más limpio - todo es una expresión. Por ejemplo, las siguientes todas son solicitudes eSQL legales: 1+2 *3 "abe" fila (1 como a, 2 como b) {1, 3, 5} e1 unión todol e2 distinto (e ) Tratamiento uniforme de sub-solicitudes: Operando a partir de su visión del mundo de tabla-céntrica SQL ha tenido la tendencia normalmente de llevar a cabo la interpretación contextual de las sub-solicitudes. Por ejemplo, en SQL, una sub-solicitud en el inciso "desde" se considera un múlti-grupo (tabla), en tanto que la misma sub-solicitud utilizada en el inciso "seleccionar" se considera una sub-solicitud escalar. A lo largo de líneas similares, una sub-solicitud utilizada en la parte izquierda de un operador "dentro" se considera una sub-solicitud escalar, en tanto que se espera que el lado derecho sea una sub-solicitud de múlticonjunto. En una modalidad, eSQL elimina estas diferencias. Una expresión tiene una interpretación uniforme que no depende del contexto en el cual se utilice. eSQL puede considerar todas sub-solicitudes que serán sub-solicitudes de grupos múltiples. Si se desea un valor escalar de la sub-solicitud, eSQL pude proporcionar el operador de "elemento" que opera en una recolección (en este instancia, la sub-solicitud), y extraer el valor singleton de la recolección. Evitar coerciones implícitas gratuitas: Un efecto secundario relacionado del problema descrito anteriormente es la noción de conversión de sub-solicitudes implícitas a valores escalares. En forma específica, en SQL, un múlti-grupo de solicitudes con un solo campo se convierte en forma implícita en un valor escalar, cuyo tipo de datos es el del campo. En contraste, las modalidades de eSQL no soportan esta coerción implícita. eSQL puede proporcionar el operador de "elemento" para extraer un valor singleton de una recolección, y un inciso "seleccionar valor" para evitar crear una envoltura-fila durante una expresión de solicitud. Seleccionar_Value - evitar la envoltura de fila implícita: SQL es un tanto ambigua con respecto al tratamiento del resultado procedente de una solicitud. El inciso-seleccionar en una sub-solicitud SQL crea implícitamente una envoltura de fila alrededor de las partidas en el inciso. Esto, por supuesto, implica que no podemos crear recolecciones de escalares u objetos - cada recolección es una recolección de filas (con un campo, si es necesario). SQL falla alrededor de esea problema, permitiendo una coerción implícita entre un tipo de fila con un campo, y un valor de unidad simple del mismo tipo de datos. En una modalidad, eSQL proporciona el inciso de seleccionar valor para saltar la construcción de filas implícita. Solamente una partida puede ser especificada en un inciso de seleccionar valor. Cuando se utiliza dicho inciso, no se construye una envoltura de fila alrededor de las partidas en el inciso de seleccionar, y se puede producir una recolección de la forma deseada. eSQL también proporciona el constructor de fila para construir filas arbitrarias. De modo que una fila seleccionar valor (e1, e2, ...) es exactamente equivalente a seleccionar e1, e2, ... En otra modalidad, las semánticas de selección pueden evitar la construcción de filas para el instancia de la partida simple, y utilizar en forma explícita, si es necesario, el constructor de fila. Si el inciso de seleccionar contiene múltiples partidas, puede continuar comportándose como en SQL. Un método alternativo y más sofisticado es prohibir las construcciones de la forma "seleccionar e1, e2 de ..." y más bien obligar a las personas a utilizar "seleccionar fila (e1, e2) de ..." todo el tiempo. Correlación-izquierda e irregularidades: El SQL estándar, las expresiones en un alcance determinado (un inciso simple tipo seleccionar, desde, etc.) no puede hacer referencia a expresiones definidas anteriormente en el mismo alcance. Algunos dialectos de SQL, incluyendo T-SQL, soportan formas limitadas de estos en la forma del inciso desde, aunque la sintaxis para utilizar dichas construcciones es pesada y requiere operaciones de aplicación y desanidar. En una modalidad, eSQL generaliza las correlaciones-izquierda en el inciso-desde, y las trata de manera uniforme. Las expresiones en el inciso desde, pueden hacer referencia a definiciones anteriores (definiciones a la izquierda) en el mismo inciso sin la necesidad de una sintaxis especial. eSQL también impone a restricciones adicionales en solicitudes que implican agrupamiento por incisos. Las expresiones en el inciso-seleccionar, inciso-tener, etc., de dichas solicitudes, pueden referirse únicamente al grupo por claves a través de sus procesamientos de señal. Las construcciones tipo las que se encuentran a continuación - las cuales son legales en SQL -son ilegales en eSQL: seleccionar t.x + t.y de T como el grupo t mediante t.x + t.y La forma correcta de realizar esto en eSQL es: seleccionar k de T como el grupo t mediante (t.x + t.y) en la forma de k Hacer referencia a columnas (propiedades) de tablas (recolecciones): En una modalidad, todas las referencias de columna en eSQL deben ser calificadas con las tablas alias. La siguiente construcción (suponiendo que "a" es una columna legal de la tabla "T") son legales en SQL, pero no en eSQL: seleccionar a de T La forma aprobada por eSQL es: seleccionar t.a como una forma T como t Las referencias no calificadas parecen varios problemas. Pueden ser ambiguas. Parecen de aspectos de captura externa/interna durante la evolución de esquemas, y además, complican la implementación. Las solicitudes-diseñadas en SQL ya utilizan referencias de columna calificadas para operar alrededor de estos problemas. Lo que eSQL hace, es simplemente imponer este alineamiento, y esto no hace que el lenguaje sea más complejo. Navegación a través de objetos: SQL utiliza la notación "." para hacer referencia a las columnas de (una fila de) una tabla. En una modalidad, eSQL extiende esta notación (nuevamente prestadas en forma pesada de los lenguajes de programación) para soportar la navegación a través de propiedades de un objeto. Por ejemplo, si "p" es una expresión del tipo Person (Persona): p.Adreess.City en la sintaxis eSQL para referenciar la ciudad de la dirección de esta persona. Muchos dialectos de SQL ya soportan esta sintaxis. Navegación a través de recolecciones: SQL no proporciona un mecanismo fácil para navegar a través de recolecciones anidadas. En una modalidad, eSQL proporciona cortes sintácticos para manejar estos casos. El operador .. en eSQL permite la proyección de una expresión procedente de una recolección. Por ejemplo, "a..b" azúcar (pone (teléfono) interfaz gráfica del usuario) realmente sintáctica para "seleccionar valor t.b de a como t". En forma similar, "a..b..(c*2)" es el azúcar (interfase gráfica de usuario) sintáctica para "seleccionar valor t2.c*2 de a como t1, tl.b como t2". El operador "?" en eSQL permite a los usuarios eliminar elementos de una recolección. Esto es similar al operador "[ ]"en XPath. Una construcción de la forma "a.?p" es realmente un corte para "seleccionar valor t de a en la forma de t cuando p". Por ejemplo, "p.?(id = 1)" realmente significa "seleccionar valor pO de p como pO cuando pO.id = 1". Cuando se trabaja con una sucesión, con frecuencia es útil tener la capacidad de seleccionar instancias de un sub-tipo de una recolección de instancias de súper-tipo. El operador oftype en eSQL (similar a oftype en Secuencias C#) proporciona esta capacidad. Lógicamente, oftype(c, T) es equivalente a "seleccionar valor tratar (x como T) de c como x cuando x es de T" Deshacer con el *: SQL soporta la sintaxis * no calificada como un alias para toda la fila, y la sintaxis * calificada (t.*) como un corte para los campos de dicha tabla. Además, SQL permite un agregado de count(*) especial que incluye nulos. Las solicitudes bien diseñadas en SQL no utilizan dicha sintaxis (al menos, las variantes "seleccionar *" y "seleccionar t.*"). El utilizar "*" es peligrosos en la presencia de la evolución del esquema. Parte del problema es que SQL no tiene forma de que los usuarios seleccionen todas las filas. En una modalidad, eSQL no soporta la construcción "*". Las solicitudes SQL de la forma "seleccionar * de T" y "seleccionar T1.* de T1, T2..." pueden expresarse en eSQL como "seleccionar valor t de T como t" y " seleccionar valor t1 de T1 como t1, T2 como t2...", respectivamente. Además, estas construcciones manejan la sucesión (capacidad de substitución de valor) gentilmente, en tanto que las variantes "seleccionar " se restringen a propiedades de alto nivel del tipo declarado. Las modalidades de eSQL no soportan tampoco el agregado count(*). Más bien, soportan la construcción count(group) para manejar esta instancia. Cambios al grupo mediante: Tal como se describió anteriormente, en una modalidad, eSQL soporta las irregularidades de las claves por-grupo, y correlaciones-izquierda entre estas claves. De hecho, las expresiones en el inciso-seleccionar e inciso-tener deben hacer referencia la grupo a través de claves mediante estas irregularidades. El inciso por-grupo produce implícitamente un agregado de nido para cada división de por-grupo - esta expresión es referida como "grupo". Las funciones de agregado en seleccionar-lista, etc., deben referirse a esta expresión para llevar a cabo la agregación.

Por ejemplo: seleccionar k1 , count(group) , sum(group.. (t.a)) de T como t por grupo t.b + t.c como k1 es la sintaxis eSQL para la siguiente solicitud SQL: seleccionar b + c, count(*), sum(a) de T por grupo b + c Agregados a base de recolección: los agregados SQL son difíciles de comprender. En una modalidad, eSQL soporta dos tipos de agregados. Los agregados a base de recolección operan en recolecciones, y producen el resultado agregado. Estos pueden aparecer en cualquier parte en la solicitud, y no requieren la necesidad de inciso por-grupo. Por ejemplo, es legal la siguiente solicitud eSQL: seleccionar t.a como a, count({1 ,2,3}) como b de T como t En una modalidad, eSQL también soporta los agregados de estilo-SQL, y los convierte implícitamente en agregados a base de recolección (basados en la recolección de "grupo"). Por ejemplo, es legal la siguiente solicitud en eSQL: seleccionar a, sum(t.b) de T como el grupo t mediante t.a como a; y se traduce internamente en una solicitud de la forma: seleccionar a, sum(group..(t.b)) como b de T como el grupo t mediante t.a como a; En una modalidad, eSQL no soporta el agregado count(*). Se debe utilizar más bien la construcción count(group) Insertar: En una modalidad, la expresión eSQL's INSERT.. VALUES es diferente a T-SQL. A diferencia de T-SQL, eSQL no permite que una lista de columna sea especificada en un inserto. Existen dos razones para esto. En primer lugar, el EDM no tiene concepto de valores por default para columnas; en segundo lugar, el método de lista de columna no se presta al manejo de sucesiones (capacidad de substitución de valor). Eliminar, Actualizar: A diferencia de T-SQL, en una modalidad, eSQL no permite un inciso-desde adicional en expresiones de eliminar y actualizar. Para expresiones de eliminar, esto no presenta un problema, ya que la solicitud puede ser escrita con una sub-solicitud. Sin embargo, para expresiones de actualizar, el inciso-desde adicional también ayuda a producir nuevos valores que serán utilizados en la cláusula-Ajustar. Propiedades y métodos sustentados: El Lenguaje de Solicitud WINDOWS® (WinQL) permite la navegación a través de recolecciones mediante el operador si la recolección por sí misma no tiene una propiedad del mismo nombre. WinQL también permite filtrar elementos de una recolección a través de la construcción "[ ]" - similar a OPath. En una modalidad, eSQL utiliza el y el operador "?" para este propósito. Nuevamente, la evolución del esquema (y captura interna) es la razón principal por la que eSQL se elige distinguir entre navegación de recolección y navegación de objeto. Y eSQL evita deliberadamente el uso de "[ ]" para predicados, para evitar aspectos de ambigüedad. Semánticas de por-orden: WinQL especifica que el orden por incisos es procesado antes del inciso-seleccionar. Esto es diferente a SQL cuando el inciso por orden es procesado en forma lógica después del inciso seleccionar. En una modalidad, eSQL puede estar más cercano a SQL en este aspecto, en tanto que WinQL toma un método tipo más parecido a XQuery. Cualquier método es razonable, y en algunas instancias, el modelo WinQL es más nítido; sin embargo, el método WinQL puede no ser lo suficientemente mejor para justificar un cambio en comportamiento de los usuarios SQL. SQL-92 realmente restringe el inciso por orden para contener únicamente referencias a las partidas en el inciso seleccionar. La mayor parte de las implementaciones permiten el inciso por orden para hacer referencia a otras partidas que están normalmente dentro del alcance. En una modalidad, ¾SQL puede seguir el último estilo. Además de las implementaciones expresadas 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 dicha especificación y las implementaciones ilustradas se consideren únicamente como ejemplos, con un alcance y espíritu real de las reivindicaciones adjuntas. APÉNDICE A: Especificación Detallada para Lenguaje de Solicitud de Ejemplo A continuación se encuentra una especificación de ejemplo, no limitante de un lenguaje de solicitud de ejemplo tal como se contempla en la presente invención. Después de la especificación que se encuentra a continuación, se encuentra una especificación de ejemplo de extensiones tales como un lenguaje de solicitud. 1 Abstracto Funcional 1.1 Descripción de Espacio del Problema El CDP proporciona una infraestructura de mapeo de relación de objeto que puede ser consumida por aplicaciones y estructuras de soporte. WinFS proporciona una experiencia de almacenamiento integrada para una amplia variedad de aplicaciones de escritorio. Tanto WinFS como CDP se construyen en la parte superior del Modelo de Datos de Entidad (EDM). El EDM es un modelo de datos de relación extendido que soporta conceptos de relación básicos, tipos robustos con sucesión y relaciones. Los usuarios necesitan la capacidad de presentar solicitudes robustas contra sus datos expresadas en términos de EDM. Aunque históricamente SQL ha sido el lenguaje de solicitud de elección para acceso a base de datos, padece de muchos inconvenientes. La carencia de soporte para tipos robustos, las construcciones no ortogonales, etc., son solo algunos de éstos. eSQL intenta atender muchos de estos problemas con SQL. eSQL está diseñado para ser similar a SQL, y proporciona cierta infraestructura mejoras adicionales con respecto a SQL. Tanto WinFS como CDP apalancan las tecnologías de acceso de datos .NET existentes - ADO.NET - para accesar y manipular datos. Un Proveedor de Datos .NET proporciona una forma un tanto uniforme de accesar datos de cualquier fuente de datos a través de Connections, Commands, DataReaders y otros de dichos objetos. Los comandos para un Proveedor de Datos .NET se expresan como cadena de caracteres, y deben estar en el dialecto nativo del proveedor (más específicamente, la fuente de datos que es confrontada por el proveedor). Como parte de los esfuerzos CDP/WinFS, se suministrarán tres nuevos proveedores - el Proveedor de Objetos, el Proveedor EDM y el Proveedor WinFS - y todos de estos utilizarán eSQL como el dialecto nativo. 2 Revisión y Principios de Diseño 2.1 Principios de Diseño Soporte de primera clase para recolecciones y objetos. eSQL debe hacer fácil para los usuarios solicitar en forma discreta sus objetos y recolecciones.

Ortogonal i dad Las construcciones en eSQL deben ser ortogonales. No deben ser interpretaciones contextúales en el uso de una construcción determinada. Capacidad de Composición (principio de diseño de un sistema que trata con las hiper-relaciones de componentes) Las construcciones en eSQL deben poder tratar las inter-relaciones de componentes dentro de otras construcciones. Similitud con SQL eSQL debe permanecer como un lenguaje tipo SQL tanto como sea posible. A menos que la desviación de SQL sea necesaria (por ejemplo, cuando es requerido por el razonamiento anterior), eSQL debe mantener fidelidad con construcciones SQL. 3 Revisión de Lenguaje eSQL incluye la noción de una expresión. Una expresión, como en otros lenguajes de programación, es una construcción que puede ser evaluada para producir un valor. Una solicitud eSQL es cualquier expresión legal. eSQL proporciona los siguientes tipos de expresiones. 3.1 Literales Un literal, como en la mayor parte de los lenguajes de programación, es simplemente un valor constante. eSQL proporciona soporte nativo para cadena de caracteres y literales numéricos, y el literal nulo especial (el cual tiene un tipo de datos de flotación libre). 3.2 Parámetros Los parámetros en eSQL permiten expresiones (y solicitudes) para referenciar valores definidos fuera de la solicitud. 3.3 Referencias Variables Las referencias variables en eSQL permiten expresiones que se refieren a otras expresiones que han sido definidas (y nombradas) anteriormente dentro del mismo alcance. 3.4 Operadores Incorporados eSQL proporciona un pequeño grupo de operadores incorporados. Esto incluye operaciones aritméticas tipo +,-,*,/> operadores de comparación (<, >, ..), operadores lógicos (y, o, no, etc.), y unos cuantos operadores misceláneos (instancia, entre, etc.). 3.5 Funciones eSQL no define cualesquiera funciones incorporadas por sí mismas. Las expresiones de función eSQL permiten el uso de cualquier función definida por el usuario (que está visible para eSQL). 3.6 Navegación de Objeto, Métodos Estas expresiones eSQL permiten que sean referenciados y manipulados en forma natural propiedades y métodos de objeto. 3.7 Funciones de Agregado Las funciones de agregado en eSQL, igual que sus contrapartes SQL, permiten operaciones de plegamiento en las recolecciones. eSQL soporta un agregado de nido, y cualquier agregado definido por el usuario. Las funciones de agregado eSQL están basadas en la recolección en cuanto a que pueden ser utilizadas en cualquier parte en una expresión. eSQL también soporta agregados a base de un grupo tipo SQL que únicamente se pueden utilizar en expresiones de solicitud. 3.8 Constructores eSQL proporciona tres tipos de constructores. Los constructores de fila pueden ser utilizados para crear un valor anónimo, estructuralmente tipificado (registro). Los constructores de objeto (constructores en C#, etc.) se pueden utilizar para construir (nombrar) objetos definidos por el usuario. Se pueden utilizar constructores de múlticonjunto para construir múlticonjuntos de otros valores. 3.9 Operaciones de Tipo eSQL proporciona operaciones que permiten que el tipo de una expresión (valor) sea solicitado y manipulado. Este incluye operación de interrogación tipo es de (similar a la expresión es en C#), las combinaciones subtipo-súpertipo igual que tratar (la expresión como en C#) y del tipo (el método OfType en las secuencias C#) y operadores de conversiones tipo combinar. 3.10 Operadores de Conjunto eSQL proporciona un conjunto robusto de operaciones de conjunto. Esto incluye operadores de conjunto tipo SQL, tipo unión (unión), intersect (intersección), except (excepto) y exists (existencia). Además, eSQL soporta operadores para eliminación de duplicados (distinto), pruebas de miembros (dentro), uniones (unión). 3.11 Expresiones de Solicitud Las expresiones de solicitud representan solicitudes de selección-de-en donde-... SQL clásicas. 4 Detalles de Lenguaje - Expresiones eSQL 4.1 Literales Nulo El literal nulo se utiliza para representar el valor nulo de cualquier tipo. Un literal nulo es considerado como de flotación libre (por ejemplo) es compatible con cualquier tipo. Los nulos tecleados pueden ser creados a través de un operador Cast con respecto a un literal nulo: seleccionar Foo (nuil, v.a. + v.b) de valúes como v -regular nuil literal seleccionar combinación cast(null como I n 116 ) de valúes como v - typed nuil Ver sección 9.6 para reglas en cuanto a en donde se pueden utilizar los literales nulos de flotación libre. Buleano Las literales buleanas se representan a través de las palabras clave cierto y falso.

Entero (Int32, Int64) Las literales de entero pueden ser del tipo Int32 ó Int64. Una literal Int32 es una serie de caracteres numéricos. Una literal Int64 son series de caracteres numéricos seguidos por una letra L. Decimales Un número de punto fijo (decimal) es una serie de caracteres numéricos, un período "." y otras series de caracteres numéricos seguido de una letra M. Flotación, Doble Un número de punto de flotación de precisión-doble es una serie de caracteres numéricos, un período "." y otra serie de caracteres numéricos seguidos posiblemente de un exponente. Un número de punto de flotación de precisiones simples (o flotación) es una sintaxis de número de punto de flotación de precisión doble seguida de una letra f. Cadena de Caracteres Una cadena de caracteres es una serie de caracteres encerrada en marcas de comillas. Las comillas pueden ser ya sea tanto comillas simples (') como comillas dobles ("). Los identificadores de comillas pueden ser representados ya sea con [ ] o " ". Por default, únicamente se permite el estilo [ ], y las construcciones " " se tratan como literales de cadenas de caracteres. El analizador eSQL puede permitir identificadores tipo " " (que serán controlados por opciones de análisis - más allá del alcance de este documento); en dicha instancia, las literales de cadenas e caracteres únicamente pueden utilizar comillas simples. Ver Sección 9.1.2 para mayor información en cuanto esto: 'hola' "x" "Esto es una cadena de caracteres !" 'por lo que es ESTO' Otros Literales eSQL no soporta literales de otros tipos de datos nativos (DateTime (Fecha Hora), Guid (Guía), etc.). 4.2 Parámetros Los parámetros son variables que son definidas fuera del lenguaje de la solicitud, normalmente a través de un API de enlace utilizado por un lenguaje huésped. Cada parámetro tiene un nombre y un tipo. Los nombre de parámetro se describen con el símbolo '@' como un prefijo antes del nombre, con el objeto de eliminarles la ambigüedad de los nombres de propiedades u otros nombres definidos dentro de la solicitud. El API de enlace de lenguaje-huésped proporciona APIs para enlazar parámetros. El siguiente ejemplo muestra el uso de un parámetro en una expresión: seleccionar c de clientes como c en donde c.Name = @name 4.3 Variable Una expresión Variable es una referencia a una expresión definida (nombrada) anteriormente en el alcance normal. Una referencia variable debe ser un identificador válido tal como se define en 6. El siguiente ejemplo muestra el uso de una variable en una expresión: seleccionar c de clientes como c 4.4 Operadores Incorporados eSQL proporciona un número de operadores incorporados, tal como se indica a continuación. 4.4.1 Aritmética Los operadores de aritmética se definen para primitivos numéricos tales como Int32, Int16, Int64, Doble, Simple y Decimal. Para operadores binarios, ocurre la promoción de tipo implícita para los operandos antes de que se aplique el operador. Los tipos de resultado de todos los operadores de aritmética son los mismos que los tipos de operando promovidos. La adición también se define para cadena de caracteres y actúa como una concatenación. 4.4.2 Comparación Los operadores de comparación se definen por primitivos numéricos tales como Byte, Int32, Int16, Int64, Doble, Simple y Decimal; Cadena de caracteres y DateTime . La promoción de tipo implícito ocurre para los operandos antes de que se aplique el operador de comparación. Los operadores de comparación siempre producen Boolean. La paridad y disparidad se definen para el tipo Boolean y cualquier tipo de objeto que tenga identidad. Los objetos no primitivos con identidad son considerados iguales y comparten la misma identidad. 4.4.3 Lógica Los operadores lógicos se definen únicamente para tipos Boolean - y siempre regresan al tipo Boolean. 4.4.4 Instancia La expresión de instancia tiene semánticas similares a la expresión de instancia TSQL. La expresión del instancia case se utiliza para elaborar una serie de pruebas condicionales para determinar que expresión producirá el resultado adecuado. Si b1, b2 bn-1 son expresiones del tipo Boolean y e1, e2, en son expresiones de algún tipo S, entonces la siguiente expresión es una expresión de instancia válido que produce un valor simple del tipo S. instancia cuando b1 entonces e1 cuando b2 entonces e2 [de otra manera vn] fin Esta forma de la expresión de instancia aplica a una serie de una o más expresiones Boolean para determinar la expresión resultante correcta. La primera expresión-civando para evaluar el valor real, produce la expresión-e/ifonces correspondiente. Las expresiones restantes no son evaluadas. Si ninguna de las condiciones-cuando son satisfechas, el resultado es el resultado de evaluar la expresión-además (si es que existe), o nulo (si es que no existe la expresión-de otra manera). Se debe observar, que la promoción de tipo implícita puede ocurrir entre diferentes expresiones de resultado (e1, e2, ... en, vn) para determinar el tipo de resultado real de la expresión de instancia. 4.4.5 Entre La expresión entre tiene las mismas semánticas que la expresión entre de SQL. Determina si una expresión determinada da como resultado un valor entre un enlace inferior y un enlace superior: e 1 entre e2 y e3 Si e1, e2 y e3 todas son expresiones del mismo tipo T, entonces la expresión anterior es una expresión de operador-entre válido. La expresión entre es una abreviatura de la escritura de dos operadores de comparación en el mismo valor. La sintaxis entre está a la mano si e1 es una expresión compleja: e1 >= e2 y e1 <= e3 La expresión no-entre puede ser utilizada para indicar el inverso de la expresión entre: e 1 no entre e2 y e3 e1 < e2 o > e3 4.4.6 Similar La expresión-similar tiene las mismas semánticas descritas para TSQL. Si determina una cadena de caracteres que coincide con un patrón, se resuelve a cierto si la cadena de caracteres coincide, y falso si no coincide. Si coincidir, patrón y escape todas son expresiones que tienen el tipo Cadena de caracteres, entonces las siguientes expresiones-similares son válidas y producen un valor Boolean: coincidir con patrón similar coincidir con patrón no similar coincidir con patrón similar escape escapar coincidir con patrón no similar pscape escapar La sintaxis de la cadena de caracteres del patrón es la misma que la sintaxis de cadena de caracteres de patrón TSQL. 4.4.7 Prueba nula (si es nula) El operador-es-nulo se utiliza para determinar si una expresión da como resultado el valor nulo. Si la expresión da como resultado el valor nulo la expresión da como resultado el valor cierto. De otra forma la expresión da como resultado el valor falso. Si e es una expresión, las siguientes expresiones son expresiones válidas que producen un Boolean: e es nulo e no es nulo Utilizar el operador-es-nulo para determinar si el elemento de una unión externa no es nulo: seleccionar c de es como c dejar fuera de la unión como ds d en donde d no es nulo y d.x = @x Utilizar el operador-es nulo para determinar si un miembro tiene o no un valor real: seleccionar c de es como c cuando c.x no es nulo 4.5 Acceso de miembros El acceso de miembros también es comúnmente conocido como el operador-de punto. Se utiliza el operador de acceso de miembro para producir el valor de una propiedad o campo de un instancia de objeto. Si m es un miembro del tipo T que tiene el tipo M, y f es un instancia del tipo T, entonces t.m es una expresión de acceso de miembro legal que produce un valor del tipo M: seleccionar p.Name.FirstName de Person como p; 4.6 Invocación de Método La invocación del método es una invocación explícita de un método. Produce el resultado de la invocación del método. Los métodos pueden ser métodos de instancia de un tipo, métodos estáticos de un tipo, o una función independiente de métodos estáticos globales (ie). Si m es un método del tipo T que regresa al tipo M y tiene parámetros de los tipos (P1, P2 Pn), y t es una instancia del tipo T y e1 es una expresión del tipo P1 y así sucesivamente, entonces t.m(e1, e2, en), es una invocación de método válida que produce un valor del tipo M. Si m es un método del tipo T que regresa al tipo M y tiene parámetros de los tipos (P1, P2, Pn), y qn es un nombre calificado que se refiere al tipo T y e1 es una expresión del tipo P1 y así sucesivamente, entonces qn.m(e1, e2, en) es una invocación de método estático válido que produce un valor del tipo M. Si m es un método T que regresa al tipo M y tiene parámetros de los tipos (P1, P2, Pn), y qn es un nombre calificado que se refiere al prefijo de espacio del nombre del método, y e1 es una expresión del tipo P1 y así sucesivamente, entonces qn.m(e1, e2, en) es una invocación de método válida que produce un valor del tipo M. Un ejemplo de una invocación de método que puede aparecer en una solicitud eSQL, puede ser el uso de métodos incorporados a tipos de datos primitivos: seleccionar tsql.substring(c.Name, 0, 2) de clientes c 4.6.1 Resolución de Sobrecarga Se puede definir más de un método con el mismo nombre. Con el objeto de determinar que método es referenciado por una expresión determinada, se deben seguir las siguientes reglas. La primera regla aplicada en sucesión que aplica únicamente un método simple es el método resuelto. 1. Existe un método con el mismo número de parámetros. 2. Un método en donde cada tipo de argumento coincide exactamente con el tipo de parámetro o es el literal nulo. 3. Un método en donde cada tipo de argumento coincide exactamente o es un subtipo de tipo de parámetro o el argumento es el literal nulo. El método con al menos un número de conversiones de sub-tipo, es el que gana. 4. Un método en donde cada tipo de argumento coincide exactamente, es un sub-tipo de, o puede ser promovido al tipo de parámetro o el argumento es el literal nulo. El método con el menor número de conversiones y promociones de sub-tipo es el que gana. 5. La expresión de invocación del método es ambigua.

Observar, que incluso un método puede ser extraído utilizando estas reglas, los argumentos aún pueden no coincidir con los parámetros. Si este es el caso, entonces los argumentos están en un error. 4.7 "Enums" "Enums" son valores numéricos integrales sólidamente escritos que son referidos por nombre. Un "enum" se especifica utilizando un nombre calificado para referirse al tipo del "enums" seguido de un operador-de punto y el nombre del "enum". Si qn es el nombre calificado para algunos "enum" E, y en es el nombre de un valor de la enumeración, entonces qn.en es una referencia "enum" válida: Color. Red 4.8 Operaciones de Tipo eSQL proporciona un número de operaciones para trabajar con tipos de valores de expresión. 4.8.1 Es De El Es de la expresión revisa si una expresión es una instancia del tipo especificado. e es de ( T ) e no es de ( T ) e es de (únicamente T ) e no es de (únicamente T ) Si e no es de algún tipo S, de compilación-tiempo, y S es ya sea un subtipo/súpertipo de T, entonces las expresiones anteriores son expresiones válidas, y regresan a un resultado del tipo Boolean. Si el tipo de e es determinado en el tiempo de corrida para ser T (o algún subtipo de T), entonces e es de T, regresa a Cierto. Si e es nulo en el tiempo de corrida, esta expresión regresa a nulo; de otra forma el resultado de esta expresión es Falso. Si se especifica únicamente el modificador único, entonces la expresión regresa a cierto, únicamente si e fue exactamente del tipo T, y no cualesquiera de sus subtipos. Las expresiones e no es de (T) y e no es de (únicamente T) son sintéticamente equivalentes a no (e es de (T)), y no (e es únicamente de (únicamente T)), respectivamente. Si S no es un subtipo o un súpertipo de T, entonces esta expresión hace surgir un error de compilación-tiempo. 4.8.1.1 Tratar La expresión tratar intenta rescribir una expresión determinada en términos de un subtipo/súpertipo: tratar (e como T) Si e tiene el tipo S y T es un subtipo de S o S es un subtipo de T, entonces la expresión anterior es una expresión de trato válida y produce un valor de tipo T. Si ni S o T son un subtipo del otro, la expresión da como resultado un error de compilación de tiempo. Se e tiene el tipo Empleado y Jefe es un subtipo de Empleado entonces la siguiente expresión produce el mismo valor de e, aunque escrito como Jefe en lugar de Empleado: tratar (e como Jefe) Si el valor de e no es realmente del tipo Jefe, entonces la expresión produce el valor nulo. 4.8.1.2 Combinación La expresión combinación tiene semánticas similares a la expresión convertir TSQL. La expresión combinación se utiliza para convertir un valor de un tipo en un valor de otro tipo. Únicamente ciertas conversiones del tipo están soportadas por el lenguaje: combinación (e como T) Si e es de algún tipo S y S se puede convertir a 7", entonces la expresión anterior es una expresión de combinación válida. T debe ser un primitivo (tipo escalar). El uso de una expresión de combinación se considera como una conversión explícita. Las conversiones explícitas pueden truncar datos o perder precisión. La lista de combinaciones válidas soportadas por eSQL se describe en la Sección 10.5 4.8.1.3 OfType Una expresión OfType especifica una expresión de tipo que es emitida para llevar a cabo una prueba de tipo contra cada elemento de una recolección. La expresión OfType produce una nueva recolección del tipo especificado que contiene únicamente los elementos que fueron ya sea equivalentes al tipo o a un sub-tipo del mismo.

Si fs es una recolección de tipo collection<S> y 7 es de un subtipo de S, entonces OfType(ts, T) es una expresión de tipo collection<T> que produce una recolección de todos los elementos e de ts, en donde el tipo individual de e, Te, es un subtipo de 7. Una expresión OfType es una abreviatura de la siguiente expresión de solicitud: seleccionar valor tratar (t como 7) de ts como t cuando t es de 7 Debido a que Jefe es un subtipo de Empleado , la siguiente expresión produce una recolección únicamente de administradores de una recolección de empleados: OfType (empleados, Jefe) También es posible elevar la combinación a una recolección utilizando el filtro de tipo: OfType (ejecutivos, Jefe) Ya que todos los ejecutivos son administradores, la recolección resultante todavía contiene todos los ejecutivos originales, aunque la recolección no es escrita como una recolección de administradores. No es posible elaborar una combinación de un tipo ilegal conocida. La siguiente expresión dará como surgimiento un error de compilación-tiempo. (Suponiendo por supuesto, que Dirección no es un subtipo/súpertipo de Empleado): OfType (empleados , Dirección) 4.9 Referencias eSQL soporta los siguientes operadores para referencias. 4.9.1 Ref El operador Ref cuando se aplica a la variable de recolección para un entityset (conjunto de entidad) produce una referencia a una entidad de dicha recolección. Por ejemplo, la siguiente solicitud regresa referencias a cada Orden: seleccionar ref (o) de Orders como o Los siguientes son usos ilegales del operador ref - la correlación variable debe resolverse a un conjunto de entidad en el alcance normal: seleccionar ref (o) de (seleccionar valué o de Orders como o) como o 4.9.2 CreateRef El operador CreateRef puede ser utilizado para fabricar referencias a una entidad en un conjunto de entidad. El primer argumento al operador es el identificador de conjunto de entidad (no una literal de cadena de caracteres), y el segundo argumento es una expresión escrita- registro que corresponde a las propiedades de clave del tipo de entidad: seleccionar ref (BadOrders, fila (o. Id)) de Orders como o Esta expresión escrita con registro debe ser estructuralmente equivalente al tipo de clave para la entidad (ie) debe tener el mismo número y tipos de campos en el mismo orden que las claves de entidad - los nombres de los campos son irrelevantes. 4.9.3 Kev El operador Key es lo inverso del operador CreateRef, y se puede utilizar para extraer la parte de clave de una expresión con tipo ref. El tipo de retorno del operador Key es un tipo de registro - con un campo para cada clave de la entidad, y en el mismo orden: seleccionar key (ref (BadOrders, fila (o. Id) ) ) de Orders como o 4.9.4 Deref El operador Deref diferencia un valor de referencia, y produce el resultado de dicha diferencia: seleccionar deref (o. CustRef) de Orders como o Si r es una referencia de tipo ref<T>, entonces Deref(r) es una expresión del tipo T que produce la entidad referenciada por r. Si el valor de referencia es nulo, o está colgando (ie) el objetivo de la referencia no existe, el resultado del operador Deref es nulo. 4.9.5 Diferenciación de Atributo Se puede navegar a través de una referencia mediante el operador El siguiente recorte extracta la propiedad Id (de Customer) navegando a través de la propiedad CustRef: seleccionar o. CustRef. Id de Ordenes como o Si el valor de referencia es nulo, o está colgando (i.e.), el objeto de la referencia no existe, el resultado es nulo. 4.10 Constructores eSQL proporciona 3 tipos de constructores - constructores de filas, constructores de objetos y constructores de múlticonjuntos. 1.10.1 Constructores de Filas Los constructores de filas se pueden utilizar para construir un registro anónimo, estructuralmente escrito de uno o más valores. El tipo de resultado de un constructor de fila es un tipo de fila - cuyos tipo de campo corresponden a los tipos de los valores utilizados para construir la fila. Por ejemplo, la expresión que se encuentra a continuación: fila (1 como a, "abe" como b, a + 34 como c) produce un valor de tipo Recordfa int, b string, c int). Todas las expresiones en el constructor de fila deben ser aliadas - si no se proporciona el alias, entonces eSQL intenta generar un alias a través de reglas de invención de nombres especificadas en 0. Las expresiones en el constructor de fila pueden no referirse a las invenciones de nombre definidas anteriormente (a la izquierda) en el mismo constructor. Es ilegal que dos expresiones en el mismo constructor de filas tengan el mismo alias. El operador de punto (.) puede ser utilizado para extraer campos de un registro (similar a extraer propiedades de un objeto). 4.10.2 Constructores de NamedType (Iniciadores de NamedType) eSQL permite que se utilicen constructores del tipo nombrado (iniciadores) para crear instancias de tipos complejos y/o tipos de entidad nombrados. La expresión que se encuentra a continuación crea una instancia de un tipo Persona (asumiendo que el tipo Persona tenga esos dos atributos): persona ("abe", 12) Los argumentos para el constructor se asume que están en el mismo orden que la declaración de los atributos del tipo. 4.10.3 Constructores de Recolección El constructor de múlticonjunto crea una instancia de un múlticonjunto de una lista de valores. Todos los valores en el constructor deben ser del tipo T mutuamente compatible, y I constructor produce una recolección del tipo Multiset<T> . La expresión que se encuentra a continuación crea un múlticonjunto de enteros: Múlticonjunto (1 , 2, 3) {1. 2, 3} 4.11 Operaciones de ajuste Esta sección contiene una variedad de operadores de ajuste. 4.11.1 Distinto La expresión distinto se utiliza para convertir una recolección de objetos en un conjunto produciendo una nueva recolección con todas las referencias duplicadas eliminadas. Si c es una recolección del tipo collection<T> , entonces distinct(c) es una expresión distinct válida que produce una recolección de tipo collection<T> que no tiene duplicados. El tipo T debe ser igualmente comparable. La expresión distinto es una abreviatura de una expresión seleccionar: distinto (c) -¥ seleccionar valor distinto c de c 4.11.2 Allanamiento La expresión allanamiento utilizada para convertir una recolección de recolecciones en una recolección allanda con los mismos elementos, solo sin la estructura anidada. Si c es una recolección del tipo collection<collection<T> , entonces flatten(c) es una expresión allanada válida que produce una nueva recolección del tipo collection<T> . La expresión allanada es una abreviatura de la utilización de la expresión seleccionar: allanada (c) -? seleccionar valor c2 de c como c1, c1.it como c2 4.11.3 Existe La expresión existe tiene las mismas semánticas que la expresión existe TSQL. Se determina si una recolección está vacía o no. Si la recolección no está vacía, la expresión exists regresa a cierto, de otra manera regresa a falso. Si c es una recolección del tipo Collection<T> , entonces exists(c) es una expresión exises válida que produce un valor simple del tipo Boolean. 4. 1.4 In. Se utiliza el operador-/n para probar un valor para el miembro en una recolección. El valor de la expresión en el lado izquierdo de la palabra clave 'in' es buscado en la recolección representada por la expresión que está en el lado derecho. Si e es una expresión con tipo T y ts es una recolección con tipo Collection<S> , y S y T tienen una relación de súpertipo/subtipo, entonces las siguientes expresiones son expresiones de operador-//? válidas: e in ts e not in ts En el siguiente ejemplo, el nombre "Bob" es buscado en el conjunto de nombres de clientes: 'Bob' in customerNames Si el valor se encuentra en la recolección, el operador-/n produce el valor cierto. Si el valor es nulo o la recolección es nula, el operador-//? produce un valor nulo. De otra forma, el operador-/'/? produce un valor falso. La forma not del operador produce lo opuesto. 4.11.5 Union. Union All Las expresiones unión y unión all en eSQL tienen las mismas semánticas que sus equivalentes TSQL. UnionAII produce una recolección que contiene los contenidos combinados de las dos recolecciones (con duplicados). Union produce una recolección con duplicados eliminados. Si c1 es una recolección del tipo Collection<T> , y c2 es una recolección del tipo Collection<S> , en donde M es el súpertipo común de T y S, entonces d unión c2 y d unión all c2 son expresiones unión válidas que producen una recolección del tipo Collection<M> . El siguiente ejemplo identifica el conjunto de todos los clientes quines ya sea viven en Washington, o son buenos clientes. La primera expresión elimina cualesquiera duplicados (por ejemplo, un buen cliente que también vive en Washington), aunque la segunda expresión conserva todos los duplicados: goodCustomers unión WashingtonCustomers goodCustomers unión all WashingtonCustomers 4.11.6 Intersección La expresión Interseccgon tiene las mismas semánticas que la expresión intersección TSQL. Determina la intersección de dos recolecciones. Si c1 es una recolección del tipo Collection<T> , y c2 es una recolección del tipo Collection<S> , en donde M es el súpertipo común de T y S, entonces d intersect c2 es una expresión intersección válida que produce una recolección del tipo Collection<M> . El siguiente ejemplo identifica el conjunto de todos los clientes quienes viven en Washington y son buenos clientes: goodCustomers intersecta WashingtonCustomers 4.11.7 Exepción La expresión Exepción tiene las mismas semánticas que la expresión exepción TSQL. Determina la diferencia de una vía, de dos recolecciones. Si c1 es una recolección del tipo Collection<T> , y c2 es una recolección del tipo Collection<S> , en donde M es el súpertipo común de 7 y S, entonces c1 exepción c2 es una expresión exepción válida que produce una recolección del tipo Collection<T> . El siguiente ejemplo, el conjunto de todos los clientes quienes no son cliente malos se identifica: alICustomers exepto badCustomers 4.11.8 Overlaps La expresión overlaps determina si dos recolecciones tienen un miembro común. Si c1 es una recolección del tipo Collection<T> , y c2 es una recolección del tipo Collection<S> , en donde M es el súpertipo común de T y S, entonces c1 overlaps c2 es una expresión overlaps válida que produce un resultado del tipo Boolean. El siguiente ejemplo revisa si cualquier cliente de Washington es un buen cliente: WashingtonCustomers overlaps goodCustomers y es un corte sintáctico para: existe (WashingtonCustomers intersecta goodCustomers) 4.11.9 Elemento La expresión elemento se extrae del elemento de una recolección de unidad simple. Si c es una recolección del tipo Collection<T> , entonces element(c) es una expresión elemento válida que produce una instancia del tipo T. El siguiente ejemplo intenta extraer el elemento de unidad simple de un conjunto de clientes malos: elemento (badCustomers) Si la recolección está vacía, o tiene más de un elemento, entonces la expresión elementoi regresa a nulo. 4.12 Navegación de Recolección eSQL proporciona un número de construcciones sintácticas que permiten un manejo más fácil de las recolecciones. 4.12.1 Proyección El operador .. (collection-project) se utiliza para proyectar elementos a través de una recolección. Si c es una recolección del tipo Collection<T> , y p es una propiedad de T con el tipo Q, entonces c.p produce una recolección del tipo Collection<Q> . Más generalmente, si c es una recolección del tipo Collection<T> , y e es alguna expresión del tipo Q, entonces ce produce una recolección del tipo Collection<Q> que contiene el resultado de evaluar e para cada elemento de c. El siguiente ejemplo tiene los nombres con mayúsculas de todos los departamentos: Departamentos ..(superior (ñame)) y es un corte para la siguiente solicitud: seleccionar valué superior (d. ñame) de Departments como d 4.12.2 Filtración El operador .? (collection-filter) se utiliza para filtrar elementos de una recolección. Si c es una recolección del tipo Collection<T> , y e es una expresión buleana con el tipo Q, entonces c.?e produce una recolección del tipo Collection<T> que contiene únicamente los elementos de c que satisfacen el predicado e. El siguiente ejemplo obtiene el conjunto de todos los departamentos que están con base en Seattle: Departamentos .? (ubicación = 'Seattle') y es un corte para la siguiente consulta: seleccionar valor d de Departments como d cuando d.location = 'Seattle' 4.12.3 Proyección Allanada El operador ... (flattened collection-proyect) se utiliza para proyectar elementos a través de una recolección anidada. Más generalmente, si c es una recolección del tipo Collection<Collection<T> , y e es alguna expresión del tipo O, entonces c.e produce una recolección del tipo Collection<Q> que contiene el resultado del primer allanamiento c, y entonces evaluar e para cada elemento c. El siguiente ejemplo obtiene los nombres con mayúsculas de todos los empleados, asumiendo que Employees es una propiedad valuada por conjunto del Department: Departamentos. Empleados... (superior (Ñame)) y es un corte para la siguiente consulta: seleccionar valor superior (e.name) de Departamentos como d, d. Employees como e 4.12.4 Filtración Allanada El operador ..? (flattened collection-filter) se utiliza para filtrar elementos de una recolección anidada. Más generalmente, si c es una recolección del tipo Collection<Collection<T> , y e es alguna expresión buleana, entonces c..?e produce una recolección de tipo Collection<T> que contiene el resultado del primer allanamiento c, y entonces la filtración de dichos elementos del resultado que no satisface en e. El siguiente ejemplo obtiene el conjunto de todos los empleados cuyo salario es mayor a 10000, asumiendo que Employees es una propiedad valuada por conjunto de Department: Departmenots. Empleados..? (salario > 10000) y es un corte para la siguiente consulta: seleccionar valor e de Departments como d, d. Emplados como e cuanbdo e.salary > 10000 Reglas de Delimitación En todos los casos anteriores, cuando se navega a través de una recolección de tipo Collection<T> , se crea una nueva delimitación, y el elemento de recolección de ese momento es enlazado a la variable it. Por conveniencia sintáctica, las propiedades (y métodos) de T también se asume que estarán dentro del alcance, aunque se consideran para cortes para el acceso-miembro con respecto a la variable it. Por ejemplo: Departamentos.. Nombre ¦ Departamentos.. (It. Nombre) 4.13 Funciones de Agregado Los agregados son expresiones que reducen una serie de valores de entradas (normalmente, pero no necesariamente, en un valor simple). Normalmente se utilizan junto con el inciso por grupo de la expresión seleccionar, y tiene restricciones de en donde realmente pueden ser utilizadas. Cada operación de agrégate está definida para uno o más tipos. eSQL no define un grupo de agregados. Simplemente depende del espacio de meta datos circundante para manejar las funciones de agregado. Agregados a base de Recolección Los agregados a base de recolección son agregados calculados en un conjunto específico de valores. Por ejemplo, las order determinadas son una recolección de todas las ordenes, se puede calcular la fecha de envío más anterior con la siguiente expresión: min (ordenes..ShipDate) Las expresiones dentro de los agregados a base de recolección son evaluadas utilizando el alcance de resolución de nombre de ambiente. Agregados a base de Grupo Los agregados a base de grupos se calculan en un grupo tal como se define a través del inciso por grupo. Para cada grupo en el resultado, se calcula un agregado separado utilizando los elementos en cada grupo como entradas al cálculo agregado. Cuando se utiliza un inciso por grupo en una expresión seleccionar, agrupando únicamente los nombres de expresión, agregados o expresiones constantes que pueden estar presentes en la proyección o inciso por orden. El siguiente ejemplo calcula la cantidad promedio ordenada por cada producto: seleccionar p, avg (o1.Quantity) de orderLines como o1 group by o1.Product como p Los agregados a base de grupos son simplemente cortes (conservan la compatibilidad con SQL) para expresiones a base de recolección. Los ejemplos anteriores realmente se traducen en: seleccionar p, avg (group.. (o1.Quantity)) de orderLines como o1 group by o1.Product como p en donde la expresión group se refiere al agregado nest producido implícitamente por el inciso por grupo. Es posible tener un agregado a base de grupos sin un inciso de por grupo explícito en la expresión seleccionar. Todos los elementos serán tratados como un solo grupo, equivalentes al caso de especificar un agrupamiento basado en una constante: seleccionar avg (oí. Quantity) de orderliness como o1 -? seleccionar avg (o1. Quantity)) de orderliness como o1 group by 1 Las expresiones dentro de cada agregado a base de grupos son evaluadas utilizando la delimitación de resolución-nombre que puede estar visible para la expresión del inciso-donde.

Para conservar la vista y detección de SQL, los agregados a base de grupo también pueden especificar un modificador all o distinto en su entrada. Si el modificador distinto es especificado, los duplicados son eliminados de la recolección de entrada del agregado, antes de que el agregado sea computarizado. Si el modificador all es especificado (o no se especifica modificador), entonces no se lleva a cabo la eliminación de duplicado. El modificador distinto realmente es una abreviatura sintáctica para el operador distinto: avg (distinto o7.Quantity) · avg (distinto oí.Quantity)) Distinción entre Agregados a base de Recolección y a base de Grupo Los agregados a base de recolección son el modo preferido de especificar agregados en eSQL. Sin embargo, los agregados a base de grupo también son soportados para facilitar los inconvenientes de transición para los usuarios SQL. En forma similar, el especificar distinto (o all) como modificadores para la entrada de agregado está soportada por el comportamiento tipo SQL, aunque el mecanismo preferido es utilizar más bien el operador distinct() La diferencia en las políticas de resolución de nombre entre agregados a base de grupo y a base de recolección puede requerir que una implementación realice intentos de evaluación bajo ambas delimitaciones. La estrategia es a favor de la interpretación como un agregado a base de recolección primero y un agregado a base de grupo segundo. 4.14 Expresiones No Soportadas 4.14.1 Predicados Cuantificados SQL permite la construcción de la forma: sal > all (seleccionar salario de empleados) sal > any (seleccionar salario de empleados) eSQL no soporta dichas construcciones. Las expresiones anteriores pueden ser expresadas en eSQL como: not exists (empleados. ? (sal > it.salary)) exists (empleados. ? (sal > it.salary)) o: not exists (seleccionar 0 de employees como e cuando sal > e.salary) existe (seleccionar 0 de employees como e cuando sal > e.salary) eSQL puede ser extendida con expresiones cuantificadas. 4.14.2 * SQL soporta el uso de "*" como un corte sintáctico en el inciso-se/ecc/onar para indicar que todas las columnas necesitan ser proyectadas. 5 Detalles de Lenguaje - Expresiones Query La expresión query es la expresión eSQL de propósito más general y es la más común para programadores familiarizados con SQL. Combina juntos muchos operadores query en una sola sintaxis. Muchos de estos operadores pueden ser especificados en forma individual; sin embargo, ninguno son tan costosos como cuando se combinan en la expresión query. A menos que se especifique lo contrario, la expresión seleccionar se comporta en forma similar a la expresión seleccionar TSQL. La expresión query está compuesta de una serie de inciso que aplican operaciones sucesivas a una recolección de objetos. Están basados en los mismos incisos encontrados en la expresión seleccionar SQL estándar; seleccionar, de, cuando, group by, having y order by. En su forma más simple, la expresión query está especificada por la palabra clave seleccionar seguida de una lista de proyección, la palabra clave de, o una expresión de fuente, la palabra clave cuando y finalmente una condición de filtración: seleccionar m de c cuando e En este ejemplo, c es una recolección de objetos de algún tipo T, m es un miembro de T con el tipo M y e es una expresión Boolean que puede referirse a uno o más miembros de T. La solicitud produce una nueva recolección de objetos con el tipo M. 5.1 Inciso De Para la mayor parte, el inciso- de tiene las mismas semánticas que se describen para TSQL. Sin embargo, es mucho menos restrictiva en sintaxis, permitiendo cualquier expresión de lenguaje que produzca una recolección que sea igual a una fuente legal. Un inciso- de es una lista separada por comas de una o más partidas del inciso- de. El inciso-de puede ser utilizado para especificar una o más fuentes de la expresión seleccionar. La forma más simple de un inciso-c/e es una expresión que identifica una recolección y un alias: de C como c Generalmente, la expresión seleccionar opera en cada elemento de la recolección de fuente en orden. Esto es referido como una interacción. Las expresiones en la lista-se/ecc/onar o el inciso- cuando pueden referirse a propiedades del elemento corriente utilizando las alias de la recolección con una variable que se refiere al elemento. 5.1.1 Partida del Inciso De Cada partida del inciso de se refiere a una recolección de fuente en la consulta. eSQL soporta las siguientes clases de partida de inciso de. 5.1.1.1 Partida de Inciso DeSimple La partida de inciso de más simple es una sola expresión que identifica una recolección y un alias: C como c La especificación alias es opcional - una especificación alterna de lo anterior de la partida del inciso de anterior puede ser: C Si no se especifica un alias, entonces los intentos eSQL generan un alias con base en la expresión de recolección. Ver 0 que se describe más adelante. 5.1.1.2 Unión de Partida de Inciso De Una unión DeClauseltem representa una unión entre dos partidas de inciso-de. eSQL soporta uniones cruzadas, uniones internas, uniones externas izquierdas y derechas y uniones externas completas - todos en forma similar a T-SQL. Como en T-SQL, las dos partidas de inciso-de implicadas en la unión deben ser independientes - no pueden estar correlacionadas. Se puede utilizar un CrossAppIy/OuterApply para estos casos. Cross Joins Una expresión cross join produce el producto Cartesiano de las dos recolecciones: C como c cross join D como d Inner Join Una inner join produce un producto Cartesiano restringido de las dos recolecciones: C como c [inner] join D como d on e Esta expresión procesa una combinación de cada elemento de la recolección izquierda emparejada contra cada elemento de la recolección derecha, en donde la condición on es cierta. Una condición on siempre debe ser especificada.

Left Outer Join, Right Outer Join Una expresión outer join produce un producto Cartesiano restringido de las dos recolecciones: C como c left outer join D como d on e La expresión procesa una combinación de cada elemento de la recolección izquierda emparejada contra cada elemento de la recolección derecha en donde la condición on es cierta. Si la condición on es falsa, la expresión aún procesa una sola instancia del elemento izquierdo emparejado contra el elemento derecho con el valor nulo. Right outer joins se pueden expresar en una forma similar. Full Outer Join Una full outer join explícita produce un producto Cartesiano restringido de las dos recolecciones: C como c full outer join D como af on e La expresión procesa una combinación de cada elemento de la recolección izquierda emparejada contra cada elemento de la recolección derecha en donde la condición on es cierta. Si la condición on es falsa, la expresión todavía procesa una instancia del elemento izquierdo emparejado contra el elemento derecho con el valor nulo, y una instancia del elemento derecho emparejado contra el elemento izquierdo con el valor nulo. Notas: ¦ Para conservar compatibilidad con Sql-92, TSql, es opcional la palabra clave outer. Por lo tanto, "left join", "right join" y "full join" son sinónimos de "left outer join", "right outer join" y "full outer join". • El inciso ON debe ser utilizado para uniones internas y externas; es ilegal para uniones cruzadas. 5.1.1.3 Aplicar Partida de Inciso De eSQL soporta dos tipos de Aplicación - CrossApply y OuterAppIy. Un cross apply produce un emparejamiento único de cada elemento de la recolección izquierda con un elemento de la recolección producida evaluando la expresión derecha. Con un cross apply, la expresión derecha es una expresión del elemento izquierdo: seleccionar c, f de C como c cross apply fn (c) como f El comportamiento de la aplicación cruzada es similar al descrito para la lista-unión. Si la expresión derecha evalúa una recolección vacía, la aplicación cruzada no produce emparejamientos para dicha instancia del elemento izquierdo. Una outer apply es similar a una cross apply, excepto que se produce aún emparejamiento incluso cuando la expresión derecha evalúa una recolección vacía: seleccionar c, f de C como c outer apply fn (c) como f Nota: A diferencia de TSql, no hay necesidad de un paso desanidado explícito. 5.1.2 Recolecciones Múltiples en el Inciso De El inciso de puede contener más de una especificación de recolección, separada por comandos. En dichos casos, se asume que las recolecciones estarán unidas. Se deben considerar estas como una unión cruzada n-way. 5.1.3 Correlación izquierda Las partidas en el inciso-de pueden referirse a partidas especificadas anteriormente. En el ejemplo que se encuentra más adelante, C y D son recolecciones independientes, en tanto que c. Ñames depende de C: de C como c, D como d, c. Ñames como e esto es lógicamente equivalente a: de (C como c join D como d) cross apply c. Ñames como e .1.4 Semánticas Lógicamente, las recolecciones en el inciso de se asumen como parte de una unión cruzada n-way - el caso de degeneración siendo una unión cruzada 1-way. Se procesan las invenciones de nombre en el inciso-ce de izquierda a derecha, y se agregan a la delimitación corriente para referencias posteriores. La cláusula de se asume que produce un múlticonjunto de filas - con un campo para cada partida en el inciso de, y representa un elemento simple de cada partida de recolección. En el ejemplo anterior, el inciso de produce lógicamente un múlticonjunto de filas del tipo Row(c, d, e), en donde los campos c, d y e se asumen que serán del tipo de elemento de C, D y c. Ñames. eSQL introduce un alias para cada partida del inciso de simple en alcance. Por ejemplo, en la solicitud que se encuentra a continuación: de (C como c join D como d) cross apply c. Ñames como e los nombres introducidos en la delimitación son c, d y e. A diferencia de SQL, el inciso de únicamente introduce las invenciones de nombre en la delimitación. Cualesquiera referencias a las columnas (propiedades) de estas recolecciones deben ser calificadas con el alias. 5.2 Inciso Cuando El inciso cuando tiene las mismas semánticas que se describen para TSQL. Restringe los objetos producidos por la expresión query limitando los elementos de las recolecciones de fuente a los que pasan la condición: seleccionar c de es como c cuando e La expresión e debe tener el tipo Boolean. El inciso-cuando se aplica directamente después del inciso-c/e, antes del agrupamiento, ordenación o proyección. Todos los nombres de elementos definidos en el inciso-de están visibles a la expresión del inciso-de. 5.3 Inciso Group By El inciso group-by tiene las semánticas similares a las descritas para TSQL. SE puede especificar una o más expresiones cuyos valores se utilizan para agrupar elementos de fuente juntos con el propósito de evaluar agregados: seleccionar e1, count (c. d1) de c group by e1, e2, .... en Cada expresión en el inciso group by debe evaluar algún tipo que debe ser comparado por paridad. Estos tipos generalmente son primitivos escalares tales como números, cadenas de caracteres y fechas. Es posible utilizar tipos complejos como condiciones group by, siempre que los tipos definan una noción de paridad. No se puede agrupar a través de una recolección. Una vez que se especifica el inciso group, ya sea en forma explícita o implícita (en virtud de tener el inciso en la solicitud), se oculta la delimitación corriente, y se introduce una nueva delimitación. El inciso seleccionar, el inciso having y el inciso order-by ya no tendrán la capacidad de referirse a nombre de elementos especificados en el inciso de. Únicamente se puede hacer referencia a las propias expresiones de agrupamiento. Para realizar esto, se pueden asignar nuevos nombres (invención de nombre) para cada expresión de agrupamiento. Si no se especifica el alias para una expresión de agrupamiento, el eSQL intenta generar uno a través de las reglas de generación de alias en 0: seleccionar g1, g2, gn de c como c1 group by e1 como g1, e2 como g2, en como gn Las expresiones en el inciso group-by pueden no referirse a nombres definidos anteriormente en el mismo inciso group-by .

Además de agrupar nombres también se pueden especificar agregados en el inciso seleccionar, inciso having y el inciso order-by. Un agregado contiene una expresión que es evaluada para cada elemento del grupo. El operador agrégate reduce el valor de todas estas expresiones (normalmente, pero no siempre, en un valor simple). La expresión agrégate puede hacer referencia a los nombres de elemento originales visibles en la delimitación de origen, o a cualesquiera nombres nuevos introducidos por el propio inciso group-by. Aunque los agregados aparecen en el inciso seleccionar, el inciso having y el inciso order, realmente son evaluados bajo la misma delimitación que las expresiones del agrupamiento: seleccionar ñame, sum (o.Price * o.Quantity) como total de orderLines como o group by o. Product como ñame Esta solicitud utiliza el inciso group-by para producir un reporte de costo de todos los productos ordenados, fragmentados por producto. Proporciona el nombre 'ñame' al producto como parte de la expresión de agrupamiento, y posteriormente hace referencia a dicho nombre en la lista seleccionar. También especifica el agregado 'sum' en la lista seleccionar que hace referencia internamente al precio y cantidad de la línea de orden. Grupos Nombrados Los grupos en si pueden tener nombres. Cuando un grupo es nombrado, se introduce un nuevo nombre en la delimitación que se refiere a la recolección de objetos que forman un inciso de grupo. El propio grupo es un agregado - el agregado nest -que simplemente agrega todas las partidas que coinciden con los criterios del grupo en un múlticonjunto. Lógicamente, el inciso group-by lleva a cabo el agrupamiento con base en las claves, y un agregado nest implícito - uno para cada grupo -que contiene la recolección de columnas sin clave para dicho grupo. Las referencias subsecuentes a agregados - agregados a base de grupo - son traducidas en agregados a base de recolección, en donde la recolección en cuestión es el agregado de nido producido por el inciso group-by: seleccionar ñame, sum (o.Price * o.Quantity) como total, mygroup de orderLines o group mygroup by o. Product como ñame En este ejemplo, el grupo mygroup es identificado en el inciso group-by y referenciado en la lista seleccionar. El nombre mygroup se refiere a una recolección de instancias Order-Line que forman un solo grupo. Cada fila de la recolección resultante tendrá tres propiedades; nombre, total y mygroup. No es necesario definir siempre el propio nombre de un grupo. Incluso sin especificar el grupo, siempre se puede accesar utilizando el nombre group: seleccionar ñame, sum (o.Price * o.Quantity) como total, group de orderLines o group by o. Product como ñame 5.4 Inciso Having El inciso having se utiliza para especificar una condición de filtración adicional en el resultado de un agrupamiento. Si no se especifica un inciso group-by en la solicitud, se asume un "group by 1" implícito - grupo single-set -. El inciso having trabaja igual que el inciso cuando, excepto que se aplica después de la operación group-by. Esto significa que el inciso having únicamente puede hacer referencia a los agregados e invenciones de nombre del agrupamiento: seleccionar ñame, sum (o.Price * o.Quantity) como total de orderLines o group by o. Product como ñame having sum (o.Quantity) > 1 Este ejemplo es el mismo que el ejemplo group-by , excepto que el inciso having restringe los grupos únicamente aquellos que tienen más de una unidad de producto en ellos. 5.5 Inciso Seleccionar La lista de una o más expresiones después de la palabra clave seleccionar es conocida como la lista seleccionar o más formalmente, con la proyección. La forma más general de proyecciones es una expresión simple. Si se selecciona algún miembro m de una recolección c, entonces se producirá una nueva recolección de todos los valores m de cada elemento c: seleccionar c, m de c Por ejemplo, si customers es una recolección del tipo customers que tiene una propiedad Ñame que es del tipo string, entonces el seleccionar Ñame de customers producirá una recolección de cadenas de caracteres: seleccionar c.Name de customers como c Incisos Seleccionar de Fila y Valor eSQL soporta dos grupos variantes del inciso seleccionar. La primera variante - seleccionar fila - es identificada por la palabra clave seleccionar, y se puede utilizar para especificar una o más partidas que pueden ser proyectadas. En forma implícita, se agrega una envoltura de fila alrededor de las partidas, con el resultado, de que el resultado de la expresión de consulta siempre es un múlticonjunto de filas - con los campos adecuados. Cada expresión en una selección de fila debe especificar un alias. Si no se especifica un alias, eSQL intenta generar un alias utilizando las reglas de invención de nombres descritas en 0. La otra variante del inciso seleccionar - seleccionar valor - es identificada por la palabrea clave seleccionar, y permite que se especifique únicamente una partida, y no se agrega en una envoltura de fila. Una row seleccionar siempre se puede expresar en términos de un valué seleccionar. Por ejemplo: seleccionar 1 como a, "abe" como b, a + 34 como c · seleccionar valué row (1 como a, "abe" como b, a + 34 como c) Modificadores All y Distinct Ambas variantes de seleccionar permiten la especificación de un modificador all o distinct. Si se especifica un modificador distinct, se eliminan los duplicados de la recolección producida por la expresión de solicitud (hasta incluyendo el inciso seleccionar). Si se especifica el modificador all, entonces no se lleva a cabo la eliminación de duplicado. Estos modificadores se conservan únicamente para ser compatibles con SQL. eSQL sugiere el uso del operador distinct en lugar, aunque soporte estas variantes, y traduce transparentemente la expresión: seleccionar distinct cal, c.a2 de T como a distinct (seleccionar a.al, c.a2 de T como a) Semánticas El inciso seleccionar se evalúa después de que sean avaluados los inciso de, clause, group by y having. El inciso seleccionar únicamente puede referirse a partidas actualmente en la delimitación (a través del inciso de, o de las delimitaciones de outer). Si una delimitación group by ha sido especificada, entonces la delimitación seleccionar se le permite hacer referencia únicamente a los alias del grupo mediante claves. Las referencias a las partidas del inciso efe se permite únicamente como parte de las funciones de agregado. 5.5.1 Desviaciones de SQL No support for * eSQL no soporta el uso de * o el * calificado para indicar que todo el inciso de (o todas las columnas de una tabla) deben ser proyectadas. Incluso en SQL, las solicitudes bien diseñada evitan estas construcciones, ya que pueden tener efectos secundarios inesperados cuando implican esquemas. eSQL permite que las solicitudes proyecten todos los registros en lugar de referenciando los alias de la recolección procedentes del inciso de. La siguiente consulta SQL: seleccionar * de T1, T2 es mucho major expresada en eSQL a través de la siguiente construcción: seleccionar t1, t2 de T1 como t1, T2 como t2 5.6 Inciso Order By El inciso order by puede especificar una o más expresiones que determinan la ordenación de los elementos en el resultado. El inciso order by es aplicador lógicamente al resultado del inciso seleccionar. Puede hacer referencia a partidas en la lista seleccionar a través de sus alias. Además, también puede hacer referencia a otras variables que están normalmente en la delimitación. Sin embargo, si se ha especificado el inciso seleccionar_clause con un modificador distinct, entonces el inciso order by pede hacer referencia únicamente a los alias del inciso-se/ecc/onar: seleccionar c como c2 de es como c order by c1.e1, c.e2, en Cada expresión en el inciso order by debe evaluar algún tipo que pueda ser comparado para una disparidad ordenada, (menor a o mayor a, etc). Estos tipos generalmente son primitivos escalares tales como números, cadenas de caracteres y fechas. Cada expresión en el inciso order by puede especificar opcionalmente criterios de clasificación. ASC (o DESC) puede especificarse para indicar que la clasificación ascendente (o clasificación descendente) es necesaria en la expresión específica. Además, para expresiones tipo cadena de caracteres, se puede especificar un inciso COLLATE para indicar la colación de cadena de caracteres que será utilizada para la ordenación. La especificación de posición, por ejemplo, order by 3, puede ser utilizada para indicar que la partida correspondiente (tercera) en la lista-se/ecc/onar no está soportada. 6 Detalles de Lenguaje - Comando 6.1 Comando Un comando eSQL es el término utilizado para toda la solicitud query. Un comando puede ser una expresión query tal como una expresión seleccionar o una expresión utilizada para insertar, eliminar o actualizar objetos. Un comando está compuesto en forma lógica de tres partes. • Un prólogo opcional • Un inciso WITH opcional ¦ Una consulta o expresión DML. Por ejemplo, imaginar que existe un tipo denominado Customer y una recolección de instancias Customer denominadas customers . Los siguientes son todos comandos válidos: customers.? (Ñame = 'Bob') seleccionar c.Name, c.Phone de customers c 6.1.1 Prólogos de Comando El prólogo de comando (opcional) puede especificar un grupo de espacios de nombre para ser utilizados. Esto se describirá más adelante en la sección de espacios de nombre. 6.1.2 Inciso WITH eSQL soporta un inciso WITH como un prefijo a una solicitud (o expresión DML). La sintaxis del inciso WITH es como se indica a continuación: withClause = WITH <common-table-expr> [, <com mon-table-expr>]* <common-table-expr> = <simpleldintif ier> como <paranthesizedExpr> Notas ¦ Las definiciones <common-table-expr> se pueden referir a expresiones de tabla común definidas anteriormente en el inciso WITH. Por ejemplo, la siguiente definición es legal: WITH tab1 como (. . . )» tab2 como (seleccionar f de tab1 como t) 6.2 Expresión de Query Una expresión Query es simplemente una expresión. 6.3 Expresión DML Las expresiones DML se describen en la siguiente sección. 7 DML eSQL soporta la inserción, actualización y eliminación de expresiones DML. 7.1.1 Insert El comando INSERT en eSQL es muy similar a la expresión INSERT en SQL estándar: [WithClause] Insert [into] <container> [<with-parent>] DE <expr> [WithClause] Insert [into] <container> [< with-parent>] <q uery_expr> [WithClause] Insert [into] <container> [<with-parent>] VALUES <expr> Semánticas <container> representa cualquier contenedor de datos. EntitySets es el contenedor más lógico. • <expr>/<query_expr> es un múlticonjunto (en los dos primeros casos), que produce un conjunto de valores para insertar en el contenedor. En el tercer caso (inciso VALUES), <expr> es del tipo de elemento del contenedor. • El WithClause se define en secciones subsecuentes. • El inciso With-parent se describe en secciones subsecuentes. Ejemplos Insert into NewCustomers seleccionar o de OldCustomers como o Insert into NewCustomers de Multiset (Customer (...), Customer (...)» ···) -- The following statement are all equivalent Insert into NewCustomers de Multiset (Customer)...)) Insert into NewCustomers seleccionar c de Multiset (Customer (. . .)) como c Insert into NewCustomers de (Customer (. . .)) Insert into NewCustomers valúes Customer (. . .) Insert into NewCustomers valúes (Customer (. . .)) Notas La expresión eSQL's INSERT..VALUES es ligeramente diferente de la de T-SQL. Para uno, los paréntesis alrededor del valor son opcionales, y no se interpretan como un constructor de filas cuando están presentes. • A diferencia de T-SQL, eSQL no permite que se especifique una lista-columna para una expresión Insert. 7.1.2 Pelete El comando DELETE en eSQL es similar a la expresión DELETE en SQL estándar. [WithClause] Delete [de] <container> [as <al¡as<] {> with-parent-clause>] [cuando <expr>] Semánticas · <container> representa cualquier contenedor de datos. Los EntitySets son el contenedor más lógico. • <expr> es un predicado (ie) del tipo buliano. • <with-parent-clause> se define más adelante. Ejem píos Delete de NewCustomers como n cuando n.id > 10 Delete de NewCustomers Notas ¦ A diferencia de T-SQL, la expresión DELETE en eSQL no permite múltiplos de los incisos. Utilizar más bien una sub-solicitud. 7.1.3 Update La expresión update en eSQL es conceptualmente similar a la expresión UPDATE en SQL estándar: Update_statement = [WithClause] UPDATE <container> [as <alias>] [<with-parent-clause>] [<set_clauses>] [<apply-clauses>] [cuando <expr>] <set_clauses> : : = SET <set_clause> [, <set_clause>] * <set_clause> : : = <field-expr> EQUAL <expr> <field-expr> : : = <expr> Semánticas <container> representa cualquier contenedor de datos. EntitySets es el contenedor más lógico. ¦ <expr> es un predicado de tipo buleano. ¦ <field-expr> es una expresión de valor-1 (i.e) puede ser una referencia de columna, una referencia a una propiedad de una columna o una expresión TREAT que implica dicha propiedad. ¦ <with-parent-clause> se define más adelante. Ejem píos UPDATE NewCustomers como n SET n.name.f irstName = UPPER (n.name.f irstName), TREAT (n.address como InternationalAddress) .countrycode = 'US' CUANDO n.name like 'ABC%' Notas • A diferencia de T-SQL, la expresión UPDATE en eSQL no permite múltiplos de los incisos. Utilizar más bien una sub-consulta. • Un atributo puede ser modificado cuando mucho una vez en la expresión UPDATE. 7.2 DML para Relaciones EDM El EDM introduce la noción de RelationshipSets como recolecciones de instancias de relaciones. Tanto las relaciones de Asociación como de Composición son modeladas a través de estos RelationshipSets. 7.2.1 Asociaciones El patrón de uso general es que se creen primero instancias de las entidades, y posteriormente se creen relaciones entre las entidades insertando en RelationshipSets. El siguiente ejemplo demuestra DMLs en dicho conjunto de relación. Asumir dos tipos de entidad Order y Customer (con EntitySets - Orders y Customers). Asumir además una relación OrderCustomer entre estas dos entidades, y OrderCustomerSet como el conjunto de relación: - - Insertar una relación entre Order y Customer Insertar en OrderCustomerSet Seleccionar OrderCustomer (ref (o), ref (c)) De Customers como c, Ordenes como o En donde o. Id = 123 y c.Name = 'ABC - - Eliminar una relación entre Order y Customer Eliminar de OrderCustomerSet como oc En donde oc. Order. Id = 123 7.2.2 Composiciones RelationshipSets que corresponden a las composiciones también se pueden actualizar. Primero se debe crear la instancia de entidad de origen. Sin embargo, a diferencia de las asociaciones, no existe un paso separado para crear la instancia descendiente. El inserto en la Composición RelationshipSet crea automáticamente la instancia descendiente. Los ejemplos de esto incluyen: - - Insertar nuevas líneas en una orden existente Insertar en OrderLineSet.Line con origen (element(seleccionar ref (o) de Orders como o en donde o. Id = 20)) seleccionar Une (. . .) de . . . - - modificar una partida de línea existente Actualizar OrderLineSet. Line como 1 con origen (element(seleccionar ref (o) de Orders como o en donde o. Id = 20)) Ajustar 1.description = . . . En donde . . . - - eliminar una partida de línea existente Eliminar OrderLineSet. Line como 1 con origen (element(seleccionar ref (o) de Orders como o en donde o. Id = 20)) en donde 1. descri ption = . . . Nota: el inciso especial "con origen como" para modificar la composición. 8 eSQL Mise 8.1 Solicitudes de Recursos eSQL permite el soporte de solicitudes de recursos permitiendo la definición de la tabla (paranthesizedExpr) para hacer referencia. Por ejemplo: CON tab1 como (multiset (1, 2, 3, 4, 5)), tab2 como (multiset (1) unión all seleccionar t2 de tab2 como t2, tab1 como t1 en donde t2 = t1) seleccionar t de tab1 como t eSQL no garantiza con respecto al término de la recursión. 8.2 Soporte para Relaciones EDM El EDM introduce la noción de RelationshipSets - las cuales son equivalentes lógicas de tablas-enlace en SQL. RelationshipSets pueden ser solicitadas igual que otras recolecciones, además, eSQL soporta auxiliares de navegación para una navegación más fácil con respecto a las relaciones. La forma general de un auxiliar de navegación es el siguiente: Seleccionar o. Id, o->OrderCustomer.Customer De Orders como o en donde OrderCustomer es el nombre de la relación, y Customer es el nombre del cliente final de la relación. 8.3 Comentarios eSQL soporta comentarios estilo T-SQL. Los comentarios eSQL pueden ser de las siguientes formas: - este es un comentario: /* este también es un comentario */ Los comentarios pueden ser utilizados en cualquier lugar en donde se espera un carácter de espacio en blanco. • Los caracteres de comentario estilo "- -" (doble-guión) pueden ser utilizados en la misma línea como un código que será ejecutado, o en una línea como tal. Cada cosa proveniente de guiones dobles al final de la línea, es parte del comentario. • /* ... */ (pares de carácter de asterisco-diagonal delantero).

Estos caracteres de comentario pueden ser utilizados en la misma línea que el código que será ejecutado, en líneas por sí mismos, e incluso sin un código ejecutable. Cualquier cosa que venga del par de comentarios abierto (/*) al par de comentarios cerrados (*/) se considera parte del comentario. Estos comentarios pueden abarcar múltiples líneas. 9 Resolución de Nombre y Otras Reglas 9.1 Identif icadores Los identificadores en eSQL se utilizan para representar áreas de expresión, referencias variables, propiedades de objetos, funciones, etc. Los identificadores en eSQL también pueden ser de dos tipos. 9.1.1 Identif icador Simple Un identificador simple, es simplemente una secuencia de caracteres alfanuméricos (y el underRank) . El primer carácter del identificador debe ser una letra de alfabeto a-z o A-Z. 9.1.2 Identificadores Encomillados Un identificador encomillado es cualquier secuencia de caracteres rodeados por corchetes o cimillas dobles. La comilla por default es un corchete. Las comillas dobles pueden ser utilizadas como el carácter de encomillado, únicamente cuando lo permite el analizador de eSQL - las opciones exactas del analizador para controlar una discreción del analizador. Se debe observar que cuando también se pueden utilizar comillas dobles como el carácter de encomillado, no se pueden utilizar para literales de la cadena de caracteres - los literales de la cadena de caracteres siempre pueden ser necesarios para utilizar comillas simples. Los identificadores encomillados permiten especificar identif icadores con caracteres que normalmente pueden ser no legales en los identificadores. Todos los caracteres entre los corchetes (o las comillas), se consideran parte del identificador, incluyendo todo el espacio en blanco. Un identificador encomillado puede no incluir los siguientes caracteres: • Línea nueva • Vueltas del carro • Tabuladores • Espacios de retroceso • [ (únicamente en el caso de [ ] de estilo). Se pueden inventar nombres de propiedad con otros caracteres de otra manera normalmente ilegales: seleccionar c.ContactName como [Contact Ñame] de customers como c seleccionar c.ContactName como "Contact Ñame" de customers como c Se puede utilizar un identificador encomillado para especificar un identif icador que normalmente podría ser considerado como una palabra reservada del lenguaje. Por ejemplo, si el tipo de Correo electrónico tiene una propiedad nombrada 'procedente', se puede eliminar la ambigüedad de la palabra reservada 'procedente' utilizando los corchetes: seleccionar e. [de] de emails como e Usted puede utilizar un identificador encomillado en el lado derecho del operador de punto: Seleccionar t de ts como t, en donde t. [a property] == 2 Para utilizar el mismo carácter que el carácter de comilla de cierre en un identificador, se utiliza dos veces. Por ejemplo: Seleccionar t de ts como t en donde t [a be] ] ] == 2 El identificador abe] es espaciado en forma adecuada. 9.2 Sensibilidad del Caso Todas las palabras clave eSQL no son sensibles a un caso (como en SQL). Los identificadores pueden ser sensibles al caso o insensibles al caso dependiendo de las opciones especificadas del analizador. Las palabras clave en eSQL siempre son insensibles al caso. 9.3 Reglas de Invención de Generación de Aleas eSQL recomienda que se especifiquen los aleas en las solicitudes siempre que sean necesarios. Los aleas son necesarios para las siguientes construcciones: • Campo de un constructor de fila • Partidas en el inciso de de una expresión de solicitud • Partidas en el inciso seleccionar de una expresión de solicitud • Partidas en el grupo del inciso group by de una expresión de solicitud • Argumentos a una expression join Aleas Válidos Cualquier identificador simple, o identif icador de un encomillado es un aleas válido. Generación de Aleas Sino se específica un aleas, eSQL intenta generar uno con base en algunas reglas simples. • Si la expresión (para la cual el aleas no es especificado) es un identificador simple o encomillado, dicho identificador se utiliza como el aleas. Por ejemplo: Fila (a, [£>]) fila (a como a, [b] como [b]) • Si la expresión es una expresión más compleja, aunque el último componente de dicha expresión es un identificador más simple, entonces dicho identificador se utiliza como el aleas. Por ejemplo: Fila (a. a1, b. [b1] ) fila (a. a1 como a1, b . [b1] como [b1]) • De otra manera surge una excepción de compilación-tiempo. 9.4 Reglas de Delimitación Las reglas de delimitación definen cuando son visibles variables particulares en el lenguaje de solicitud. Algunas expresiones o manifestaciones introducen nuevos nombres. Las reglas de delimitación determinan en donde se pueden utilizar dichos nombres, y cuando y donde una nueva declaración con el mismo nombre en la forma de otro, puede ocultar su predecesor. Cuando los nombres son definidos, se dice que están definidos dentro de la delimitación. Una delimitación cubre una región de la solicitud. Todas las expresiones o referencias a nombres dentro de una cierta delimitación pueden ver nombres definidos dentro de dicha delimitación. Antes de que comience una delimitación y después de que finaliza, no se puede hacer referencia a los nombres definidos dentro de la delimitación. Las delimitaciones pueden ser anidadas. Parte del lenguaje introduce nuevas delimitaciones que cubren regiones que pueden contener otras expresiones de lenguaje que también introducen delimitaciones. Cuando las delimitaciones están anidadas, se puede hacer referencias a nombres definidos dentro de la delimitación interna en la que dicha referencia está dentro, así como cualesquiera nombres definidos en cualesquiera debilitaciones externas. Cualesquiera de dos delimitaciones definidas dentro de la misma delimitación, se consideran delimitaciones hermanas. No se pueden hacer referencias a nombres definidos dentro de delimitaciones hermanas. Si un nombre es declarado dentro de una delimitación interna que coincide con un nombre declarado en una delimitación externa, las referencias dentro de dicha delimitación o dentro de delimitaciones declaradas dentro de dicha delimitación se refieren únicamente al nombre declarado recientemente. El nombre en la delimitación externa se oculta. Incluso dentro de la misma delimitación, los nombres pueden no ser referenciados antes de que sean definidos. Pueden existir nombres globales como parte del ambiente de ejecución. Esto puede incluir nombres de recolecciones persistentes o variables ambientales. Esta delimitación que los contiene es la delimitación externa. Los parámetros no están en una delimitación. Ya que las referencias a los parámetros incluyen sintaxis especial, los nombres de los parámetros no colisionan con otros nombres en la solicitud. 9.4.1 Expresiones Query La expresión query introduce una nueva delimitación. Los nombres definidos en el inciso-de de introducen en la delimitación-de en orden de aparición, de izquierda a derecha. En la lista-yo/n, las expresiones se pueden definir a nombres definidos anteriormente en la lista. Las propiedades públicas (campos, etc) de elementos identificados en el inciso-de no se agregan a la delimitación-de (- siempre deben ser referenciadas a través del nombre calificado con aleas. Normalmente, todas la partes de la expresión seleccionar son consideradas dentro de la delimitación-de. El inciso group-by también introduce una nueva delimitación hermana. Cada grupo puede tener un nombre de grupo que se refiere a la recolección de elementos en el grupo. Cada expresión de grouping también introducirá un nuevo nombre en la delimitación-aroup. Además, el agregado de nido (o el grupo con nombre) también se agrega a la delimitación. Las expresiones de grouping por sí mismas están dentro de la delimitación-de. Sin embargo, cuando se utiliza un inciso group-by, la lista-se/ecc/onar- (proyección), el inciso-fra ngr y el inciso-order-fcy se consideran que están dentro de la delimitación-group, y no de la delimitación-de. Los agregados obtienen tratamiento especial, y estos se describen más adelante. La lista-se/ecc/onar puede introducir nuevos nombres en la delimitación, por orden. Las expresiones de proyección a la derecha se pueden referir a nombres proyectados en el lado izquierdo. El inciso orderby puede referirse a nombres (aleas) especificados en la lista seleccionar. El orden de evaluación de los incisos dentro de la expresión seleccionar determina el orden en que los nombres son introducidos en la delimitación. El inciso de es evaluado prjmero, seguido de inciso cuando, el inciso grouping , el inciso having, el inciso seleccionar y finalmente el inciso order-by.

Manejo de Agregado eSQL soporta dos formas de agregados- agregados a base de recolección y agregados a base de grupo. Los agregados a base de recolección con la construcción preferida en eSQL, en tanto que los agregados a base de grupos son soportados simplemente por compatibilidad SQL. Cuando se resuelve un agregado, eSQL intenta primero tratarlo como un agregado a base de recolección. Si esto falla, entonces eSQL transforma la entrada del agregado para ser una referencia al agregado de nido, e intenta resolver esta nueva expresión. Por ejemplo: avg (t.c) avg (group .. (í.c)) 9.4.2 Operaciones de Filtro/Provecto de Recolección Para los operadores de filtro/proyector de recolección (..., ? y ..?), se crea una nueva delimitación para la proyección/predicado, y su nombre se agrega implícitamente en la delimitación - para representar cada elemento de la recolección. Además, por simplificad, los miembros públicos del elemento de recolección también se agregan en la delimitación -normalmente justo para la duración de la evaluación de la proyección/predicado. Por ejemplo: Departments.. Ñame Departments..(it.Name) produce un multiconjunto de nombres de departamento - en donde cada Department se asume que tiene una propiedad de Ñame. 9.5 Espacios de Nombre eSQL introduce espacios de nombre para atender el aspecto de conflictos de nombre de identificadores globales tales como nombres de tipo, conjuntos de identidad, funciones, etc. El soporte de espacio de nombre en eSQL es muy similar al modelo CLR. eSQL proporciona el inciso using que puede ser utilizado en el prólogo de Command. Dos formas del inciso using son proporcionadas - espacios de nombre calificados (en donde se proporciona un aleas más corto para el espacio de nombres) y nombres de espacio no calificados: using System. Data. TSql; using tsql = System . Data. TSq I ; Reglas de Resolución de Nombres Si un identif icador no puede ser resuelto en las delimitaciones locales, entonces eSQL intenta localizar el nombre en las delimitaciones globales (ie) de los espacios de nombre. eSQL intenta primero cotejar el identif icador (prefijo) con uno de los espacios de nombre calificados. Si existe una coincidencia, entonces eSQL intenta resolver el resto del identif icador en el espacio de nombre especificado - si no se encuentra coincidencia, surge una excepción: utilizando taql = System. Data.TSql; utilizando winfs = System. Storage.WinFS; seleccionar taql.substr(p.Name) de Person como p seleccionar i.ltemld de Items como i en donde i es de winfs. Contact Posteriormente eSQL intenta probar todos los espacios de nombre no calificados (especificados en el prólogo) del identificador. Si el ¡dentificador puede ser localizado exactamente en un espacio de nombre, entonces dicha localización es regresada. Si más de un espacio de nombre tiene una coincidencia para dicho identificador, surge una excepción. Si no se pueden identificar espacios de nombre del identificador, entonces eSQL pasa el nombre en la siguiente delimitación hacia fuera (el objeto Command/Connection): utilizando System. Data. TSql; seleccionar substr(p.Name) de Person como p Diferencias del Modelo CLR Una diferencia del modelo CLR vale la pena mencionarse. En el CLR, se pueden utilizar espacios de nombre parcialmente calificados - eSQL no permite esto. Por ejemplo, el C#, los siguientes es legal, en tanto que el equivalente no es legal en eSQL: utilizando System. Data .TSql; evitar main() ( int. x = Y. Z.Foo (); - referencia al método Foo de la clase Z en - espacio de nombre System. Data. TSql. Y ) Uso de ADO.NET Se expresan manifestaciones de Solicitudes/DML a través de comandos ADO.NET. Los comandos pueden ser construidos en objetos de Conexión . Los espacios de nombre pueden ser especificados como parte de los objetos de Command y Connection también. Si eSQL no puede resolver un identificador dentro de su propia solicitud, entonces se prueban los espacios de nombre externos (a través de reglas similares). La solicitud, objetos Command y Connection forman anillos de espacios de nombre - en donde cada anillo se prueba primero. 9.6 Literales Nulos e Inferencia de Tipo Tal como se describió anteriormente, los literales nulos con compatibles con cualquier tipo en el sistema tipo eSQL. Sin embargo, para que el tipo de un literal nulo sea inferenciado correctamente, eSQL impone ciertas restricciones en cuanto a cuándo se puede utilizar el literal nulo. Aplica las siguientes reglas. Nulos escritos Los nulos escritos (i.e.) "cast(null como Int16)" se pueden utilizar en cualquier parte; no existe necesidad adicional de inferenciar el tipo, ya que el tipo es conocido en ese momento. Literales nulos de flotación libre Los literales nulos de flotación libres se pueden utilizar dentro de los siguientes contextos: • Como un argumento a una expresión cast/treat - esto es el mecanismo recomendado para producir una expresión nula escrita.

• Un argumento o un método o a una función. (Aplican reglas de sobrecarga estándar, y si no se puede eliminar una sobrecarga, entonces surge un error de compilación). Como uno de los argumentos de una expresión arithmetic tal como +, -, , /. El otro argumento(s) no pueden ser literales nulos; de otra forma no es posible la inferencia del tipo. • Como uno de los argumentos a una expresión logical (y/o/no) - todos los argumentos son conocidos para ser del tipo booleano. • Como el argumento de una expresión "/s nuil" o "is not nuil", las expresiones "nuil is nuil" y "nuil is not nuil" son legales (aunque ridiculas)/ • Como uno o más de los argumentos de una expresión ///re - todos los argumentos se espera que sean cadenas de caracteres. • Como uno o más de los argumentos a un constructor con tipo nombrado. • Como uno o más de los argumentos a un constructor de multiconjunto. Sin embargo, al menos un argumento al constructor de multiconjunto debe ser una expresión diferente a un literal nulo. • Como una o más de las expresiones then/else en una expresión de a case. Al menos una de las expresiones then/else en la expresión del caso debe ser una expresión diferente a un literal nulo. Los literales nulos de flotación libre no pueden ser utilizados en otros escenarios. Algunos de estos escenarios (no exhaustivos), incluidos únicamente por ilustración) incluyen · Argumentos a un constructor de fila. Notas Las expresiones is nuil y is not nuil se consideran especiales. 10 Sistema Tipo eSQL eSQL opera en, y produce instancias de Modelo de Datos de Identidad (EDM). Este documento no entrará en los detalles del EDM; más bien, se invoca un par de partidas de interés especial. 10.1 Tipos de Filas Las filas (registros a.k.a.) son estructurales por el miembro. Una estructura de la fila depende de la secuencia de los miembros escritos y nombrados de que esté compuesta. Una fila es un Tipo en Línea EDM - no tiene identidad y no puede ser heredada de. Los casos del mismo tipo de fila son equivalentes y los miembros son respectivamente equivalentes. Las filas no se comportan más allá de su equivalencia estructural. Las filas no tienen equivalente en el tiempo de corrido de lenguaje común. Las solicitudes pueden dar como resultado estructuras que contienen filas o recolecciones de filas.

El enlace API entre las solicitudes eSQL y el lenguaje huésped definirá como las filas son materializadas en el resultado de la solicitud. En ADO.NET, las filas aparecerán como DataRecords. 10.2 Recolecciones Los tipos de recolección representan cero o más instancias de otros objetos. El EDM soporta varios tipos de recolecciones - incluyendo multiconjuntos, listas, etc. Este documento únicamente trata con Multiconjuntos. 10.3 Capacidad de Nulificación En el EDM, la capacidad de nulificación es una restricción en una propiedad, y no una faceta de un propio Tipo. Cada tipo en EDM es nulificable. Los literales Nuil en eSQL se consideran que son compatibles con cada otro tipo en EDM. 10.3.1 Semánticas Nulas Los nulos en eSQL se comportan en forma muy similar a los Nulos en TSql. Específicamente, la mayoría de las expresiones que operan en un nulo, regresan nulas. Esto incluye: « Expresiones Aritméticas • Expresiones Lógicas • Expresiones de Tipo. Las siguientes expresiones pueden no regresar nulas cuando uno o más de sus argumentos son nulos: · Constructores (tipo, fila, multiconjunto) • Funciones/Métodos • Operadores is nuil y is not nul • Otros. 10.4 Promoción de Tipo Implícita eSQL define una variedad de operadores binarios y unarios comunes, tal como adición, multiplicación, y negación con respecto a tipos de datos primitivos tales como un entero, flotación, y cadena de carácter. Normalmente, los operadores binarios tal como la adición, operan en dos instancias del mismo tipo de datos. Sin embargo, algunas veces es legal solicitar un operador que trabaje en dos instancias de tipos diferentes; por ejemplo adición y entero y una flotación. Para que esto funcione, uno de los dos operandos debe ser promovido al tipo del otro. En general, este es el tipo con la mayor precisión, de modo que no hay pérdida de datos durante la conversión. En algunas circunstancias, ambos operandos son promovidos a un tercer tipo para asegurar que no existe pérdida de datos. La siguiente tabla describe las promociones de tipo implícitas incorporadas en el lenguaje. En la primera columna describe el tipo de base y la segunda columna describe las promociones más inmediatas que pueden ser realizadas a dicho tipo. Por ejemplo, un I n 116 se puede promover a un Int32. Aún, también puede promoverse a un Int64, ya que Int32 puede promoverse a un Int64.

Tipo Promociones Boolean Ninguna SByte Int16, Simple, Decimal Int16 Int32, simple, Decimal Int32 Int64, doble, Decimal Int64 Decimal Byte Int16, Ulnt16, Simple, Decimal Ulnt16 Int32, Ulnt32, Simple, Decimal Ulnt34 Int64, Ulnt64, Doble, Decimal Ulnt64 Decimal Simple Doble, Decimal Doble Decimal Decimal Ninguno Carácter Cadena de carácter Cadena de carácter Ninguno Fecha tiempo Ninguno Guía Ninguno Los tipos que no se describen o que se describen como teniendo una promoción de 'ninguno' no pueden ser promovidos implícitamente. Si se desea conocer la promoción de tipo correcto cuando se intenta agregar un I n 116 a una flotación, se puede ver la tabla, para ver que un I n 116 de hecho se promoverá a una flotación, pero una flotación no se promoverá a un I n 116. Por consiguiente, el I n 116 se promoverá a una flotación, de modo que se pueden agregar juntas dos flotaciones. Un ejemplo ligeramente más complicado puede tener un Int32 agregado a una flotación. Observar que un I n 132 no promoverá a una flotación, y la flotación no promoverá a un Int32. Sin embargo, tanto Int32 como la flotación promoverán a un doble. Por consiguiente, ambos operandos son promovidos al doble, y dos dobles se agregan juntos. 10.5 Conversiones tipo legales A continuación se encuentra una tabla de conversiones legales entre tipos de datos primitivos 11 Enlaces de Lenguaje del Ordenador El enlace de lenguaje del ordenador es el API a través del cual se interactúa con eSQL. eSQL ha sido diseñado como un lenguaje de solicitud que es accesado a través de un API procedente de un ordenador que programa el lenguaje en la forma en que el TSQL normal es accesado por los programadores utilizando el acceso de datos de Microsoft API's. En forma conceptual, los datos que están siendo solicitados residen en alguna parte fuera del dominio del lenguaje del ordenador, en una base de datos u otro almacén persistente, o una estructura de datos que es opaca para los operadores de lenguaje normal. El mecanismo de acceso de datos preferido para eSQL es ADO.NET. El objeto de Command en ADO.NET tiene una propiedad de CommandText (la cual puede ser ajustada a una cadena de caracteres de solicitud eSQL). El método Execute en el objeto Command regresa un DataReader (el cual soporta una interfase lEnumerator). El DataReader es lógicamente una recolección de DataRecords , en donde un DataRecord representa un solo elemento del resultado. 12 Gramática 12.1 Comando command :: = [prolog] [utilizando inciso] (query \ dml ) prolog :: = { NamespaceDecI; }* NamespaceDecI :: = utilizando (AliasedNamespaceDecI | UnaliasedNamespaceDecI) AliasedNamespaceDecI :: = simpleldentifier = identifier UnaliasedNamespaceDecI :: = Identifier withClause :: - con; withClauseltemList withClauseltemList :: = withClauseltem I withClauseltemList, withClauseltem withClauseltem :: = simpleldentifier como paranthesizedExpr 1 2 .2 D M L dml Insert \ update \ delete Inserí Insertar [ en ] exp. [ with-parent-clause ] desde expr | insertar [ en ] exp. [ with-parent-clause ] queryExpr | insertar [ en ] exp. [ with-parent-clause ] Valores expr delete Eliminar [ de ] aliasedExpr. [ with-parent-clause ] [en donde expr] update actualizar aliasedExpr [ with-parent-clause ] set-clause /cuando expr] with-parent-clause con parenthesizedExpr de origen set-clause ser set-clause-item-list set-clause-item-list set-clause_item set-clause-item-list, set-clause-item set-clause-item simple-set-clause-item simple-set-clause-item expr = expr 2.3 Ex p res i o nes d e so l i c itu d query :: = generalExpr generalExpr expr | queryExpr expr :: = HteralExpr | parameterExpr | variableRefExpr | builtinExpr | dotExpr | constructorExpr | methodExpr I aggregateExpr | collectionNavigationExpr | relationshipNavigationExpr | setOpExpr | paranthesizedExpr exprList expr [, expr ]* aliasedExpr expr como identifier \ expr paranthesizedExpr ( generalExpr ) HteralExpr numericLiteral | stringLiteral | booleanLiteral | nullLiteral parameterExpr @simplelden tifier variableRefExpr identifier dotExpr expr, identifier methodExpr [ expr, ] identifier ([todo] | distinto ] [exprList ] ) constructorExpr rowConstructorExpr | objectConstructorExpr | multisetConstructorExpr rowConstructorExpr :: = fila {aliasedExpr [ , aliasedExpr ] * ) multisetConstructorExpr :: = multiconjunto ([ exprList ] ) | ( [ exprList ] ) objectConstructorExpr [ identifier ,]* identifier ( [exprList ] ) aggregateExpr [ identifier ,]* identifier ( [ todo | distinto ] ) exprList ) builtinExpr arithmeticExpr comparisonExpr logicalExpr likeExpr isNullExpr betweenExpr caseExpr typeExpr refExpr derefExpr keyExpr createxpr arithmeticExpr expr + expr ' expr - expr expr * expr expr | expr expr % expr + expr - expr comparisonExpr = expr < expr expr > expr expr = expr expr < = expr expr >= expr expr <> expr logicalExpr expr y expr expr && expr expr o expr expr 11 expr no expr ! expr isNullExpre expr es [ no ] nuil likeExpr expr [ no ] like expr escapar betweenExpr expr [ no ] entre expr y expr dereFExpr deref (expr) refExpr ref ( identifier ) creaíeRefExpr crearref ( identifier, expr ) keyExpr clave ( expr ) caseExpr Caso whenList [ elseExpr ] final whenList whenExpr { whenExpr} whenExpr cuando expr entonces expr elseExpr Al más expr typeOpExpr tratar ( expr como expr) | combinar ( expr como expr) | expr es [ no ] de ( [ únicamente ] expr ) | del tipo ( expr, expr) relationshipNavigationExpr expr -> identifier, identifier collectionNavigationExpr expr „ expr | expr. ?- expr | expr ... expr | expr ..? expr setOpExpr expr unión expr | expr unión all expr | expr intersect expr | expr except expr | expr overlaps expr | expr in expr | exists (generalExpr) | element ( general Expr ) | flatten ( generalExpr ) queryExpr seleccionarClause [ cuandoClause ] [ groupByClause ] [ havingClause ] [ orderByClause ] seleccionarClause rowSeleccionarClause I valueSeleccionarClause rowSeleccionarClause seleccionar [ todo distinto ] aliasedExpr { , aliasedExpr } valueSeleccionarClause seleccionar valor [ todo | distinto ] expr dedause de deClauseltem {, deClauseltem } deClauseltem simpleDeClauseltem | jointDeClauseltem | {joinDeClauseltem ) | applyDeClauseltem | {applyDeClauseltem ) simpleDeClauseltem expr \expr como simpleldentifier jointType left [ outer ] join | rigth [ outer ] join | [ inner] join | full [ outer | join joinDeClauseltem deClauseltem cross join deClauseltem | deClauseltem JoinType DeClauseltem on, expr applyType cross apply | outer apply ApplyDeClauseltem deClauseltem applyType deClauseltem cuandoClause cuando expr groupByClause grupo [ Identifier ] mediante aliasedExpr havingClause having expr orderByClause order by orderByClauseltem {, orderByClause} orderByClauseltem expr [ collate collation ] [ ase | desc ] collation simpleldentifier identifier quoteldentifier \ simpleldentifier quotedldentifier [ unicodeCharacters ] I " unicodeCharacters" unidodeCharacters unicodeCharacter { unicodeCharacter } simpleldentifier letter { setter | digit | _ } numericLiteral int32Literal | int64Literal | doubleLiteral | floatLiteral I decimalLiteral nullLiteral nuil booleanLiteral true | false int32Literal digit { digit } int64Literal integerLiteral L doubleLiteral digit { digit } , digit { digit } [(E\e)[ + \-]digit {digit}] floatLiteral doubleLiteral f decimalLiteral digit { digit } , digit { digit } M stringLiteral ' { unicodeCharacter } ' | " { unicodeCharacter } APENDICE B: Especificación Detallada de Expresiones al Lenguaje de Solicitud de ejemplo 1 Revisión General 1.1 Propósito Este documento detalla las extensiones (funciones) al lenguaje de solicitud eSQL para WinFS/CDP. eSQL proporciona soporte para invocar funciones, aunque no proporciona cualesquiera funciones incorporadas por sí mismas. (Operadores tipo +, -, etc, se manejan en forma distante, y se asume que serán soportados dentro del propio lenguaje). Los usuarios de los lenguajes tipo T-SQL y otros dialectos de SQL están acostumbrados a un conjunto pesado de funciones incorporadas. El propósito de este documento es describir como eSQL puede extenderse para atender estos requerimientos. Fundamentalmente, todas las funciones en eSQL se tratan igual: como funciones definidas por el usuario. eSQL utiliza espacios de nombre para definir diferentes contenedores de funciones en un modo similar al uso de espacios de nombre que contienen tipos. Los proveedores pueden definir dichos espacios de nombre con el conjunto de funciones asociadas, y los hacen disponibles a través de servicios de metadatos a usuarios de eSQL. Este documento se enfoca en el conjunto específico de construcción en funciones disponibles del Servidor SQL y WinFS en los espacios en nombre que quedan disponibles a través de esto. Este documento no atiende la cuestión de cómo los proveedores suministran esta lista de funciones, y cómo éstas son cargadas por el resto del sistema. Estas extensiones son agrupadas por los proveedores de almacenamiento que las soportan. La lista de proveedores es como se indica a continuación: 1. Servidores SQL 2000. 2. Servidor SQL 2005. Este proveedor soporta todas las funciones SQL 2000. 3. WinFS. Este proveedor soporta todas las funciones SQL 2005 y SQL 2000. La siguiente tabla resume la funcionalidad: Favor de consultar las secciones posteriores del documento para casos descritos como soporte parcial en la tabla anterior. 1.2 Mecanismo de Extensión Los detalles en cuanto al mecanismo de extensión eSQL que permiten la funcionalidad de extensión se pueden encontrar en la sección 9.4 (Espacio de nombres) de la especificación del Lenguaje eSQL. Se debe observar que los espacios en nombres parciales no están soportados; ver la especificación del lenguaje eSQL para más detalle. Los espacios de nombre pueden ser importados en una solicitud utilizando el inciso using de eSQL. Como alternativa, se pueden especificar uno o más espacios de nombre fuera de los límites de la solicitud, por ejemplo, comparte de los ejemplos Command/Connection. 1.3 Ejecución de Extensión La ejecución de solicitud (incluyendo funciones de extensión) siempre sucede en el almacén. Además, a menos que se observe lo contrario, las semánticas de las funciones de extensión se espera que sean las mismas que el servidor. Los analizadores eSQL validan la asignatura de las invocaciones de función, sin embargo, se lleva a cabo cualquier validación semántica en el almacén subyacente. 2 Diseño Detallado 2.1 Agregados Las funciones de agregado llevan a cabo en el cálculo multiconjunto de valores y regresan un valor simple. Con la excepción de COUNT, las funciones de agregado ignoran valores nulos. Las siguientes funciones SQL disponibles están soportadas: Las funciones de agregado ignoran los valores nulos cuando se computa el valor (excepto para el conteo). Asimismo se debe observar que no está soportado count(*). Las funciones de agregado se pueden utilizar en un predicado y en una definición de proyección. Además, los agregados soportan un modo "distinto" (similar al soporte SQL) en tipos de datos que soportan la variedad. El tipo de retorno de estas funciones está basado en el tipo de la propiedad de la función contra la cual está siendo ejecutado. Por lo tanto, por ejemplo, avg(int) regresará un int. No puede esperarse que esto sea el promedio de 2,3 que regresará 2 en lugar de 2.5. Para trabajar con esto el usuario necesita combinar en forma explícita la propiedad a un tipo que tenga la precisión correcta, por ejemplo, avg(cast(intProperty como doble)). 2.1.1 Espacio de nombre Estas funciones están en el nombre de espacio System. Data. TsqLAggregates. 2.1.2 Ejemplos utilizando System. Data. TSql.Aggregates; seleccionar count (i.Children.) como Count de Items como i;. seleccionar max (i.DisplayName) de Items como i group by i.Gender; 2.1.3 Plataformas Soportadas Soportadas en: SQL 2000, SQL 2005 y WinFS. 2.2 Funciones de Cadena de Caracteres Estas funciones escalares llevan a cabo una operación en un valor de entrada de cadena de caracteres y regresan un valor de cadena de caracteres o numérico.

Favor de observar que todas las funciones de cadena carácter tienen índices basados en uno. 2.2.1 Espacio de Nombre Estas funciones están en el espacio de nombre Systern.Data. Tsql. String. 2.2.2 Ejemplos utilizando System. Data. String; seleccionar substring (reverse (i.DisplayName), 1, 5) de Items como i. 2.2.3 Plataformas Soportadas Soportadas en: SQL 2000, SQL 2005 y WinFS. 2.3 Funciones Matemáticas Estas funciones escalares llevan a cabo un conjunto en común de operaciones matemáticas.

Descripción Regresa el valor absoluto, positivo de la expresión numérica terminada. Regresa el ángulo, en radianes, cuyo coseno es la expresión de flotación determinado, también denominada arcoseno. Regresa el ángulo, en radianes, cuyo seno es la expresión de flotación determinada (también denominada arcoseno). Regresa el ángulo en radianes cuya tangente es la expresión de flotación determinada (también denominada arco tangente). Regresa el ángulo, en radianes, cuya tangente está entre las dos expresiones de flotación determinadas (también denominada arco tangente). Regresa el entero más pequeño menor o igual a la expresión numérica determinada. Una función matemática que regresa el coseno trigonométrico es de un ángulo determinado (en radianes) en la expresión determinada. Regresa el valor exponencial de la expresión de flotación determinada. Regresa el entero más grande menor o igual a la expresión numérica determinada. Regresa el logaritmo natural de una expresión de flotación determinada. Regresa el logaritmo de base 10 de la expresión de flotación determinada. Regresa el valor de la expresión determinada (x) a la potencia específica (y). Regresa una expresión numérica, redondeada a la longitud o precisión específica. Regresa el signo positivo (+1 ), cero (0), o negativo (-1) de la expresión determinada. Regresa la raíz cuadrada de la expresión determinada. Regresa la tangente de la expresión de ingreso. Determina un ángulo en radianes, y regresa el ángulo correspondiente en grados. Regresa radianes cuando una expresión numérica, en grados, es ingresada.

Regresa un valor de flotación aleatorio de 0 a 1. Regresa el seno trigonométrico del ángulo determinado (en radio) en una expresión numérica aproximada (flotación) Regresa el cuadrado de la expresión determinada. Regresa el valor constante de Pl como una flotación.

Esta s fu n ci o nes está n e n e l es paci o d e n o m b re Syste rn . Data . Tsql. String. 2.3.2 E je m p l os U ti l iza n d o System . Data . TSql, Ma th; sel ecci o n a r P l () de Items como i. 2.3.3 Plataformas Soportadas Soportadas en: SQL 2000, SQL 2005 y WinFS. 2.4 Funciones de Fecha Estas funciones escalares llevan a cabo una operación en el valor de entrada de fecha y tiempo y regresan un valor de cadena de carácter, numérico o de fecha y tiempo: Función Descripción DateAdd(x,y,z) Regresa un valor de fecha tiempo con base en la adición de un intervalo a la fecha especificada. Cuando x es parte de la fecha (por ejemplo, Año, Mes, Día) y "y" es un número y z es una fecha. DateD¡ff(x,y,z) Regresa el número de límites de fecha y tiempo cruzado entre dos fechas específicas. Cuando x es una parte de fecha (por ejemplo, Año, Mes, Día) y y es la fecha de inicio y z es la fecha de finalización. DateName(x,y) Regresa una cadena de carácter que representa la parte de fecha especificada de la fecha especificada. Cuando x es una parte de fecha (por ejemplo, Año, Mes, Día) y y es la fecha. DatePart(x,y) Regresa un entero que representa la parte de fecha especificada de la fecha especificada. Cuando x es una parte de fecha (por ejemplo, Año, Mes, Día) y y es la fecha. Day(x) Regresa un entero que representa la parte de fecha de Día de la fecha especificada. Cuando x es la fecha. GetDate() Regresa la fecha y tiempo corrientes (en el servidor) como una DateTime. Datetime.Kind se ajustará al tiempo local. GetUtcDate() Regresa el valor de fecha tiempo en formato UTC. DateTime se ajustará a UTC. Se debe observar que puede haber una pérdida en precisión. Month(x) Regresa un entero que representa la parte de fecha Month de la fecha especificada. Cuando x es la fecha. Year(x) Regresa un entero que representa una parte de fecha de Año de la fecha especificada. Cuando x es la fecha. 2.4.1 Espacio de Nombre Estas funciones están en el espacio de nombre Systern.Data. Tsql. String. 2.4.2 Ejemplos La parte de fecha necesita ser especificada como un literal de cadena de carácter: utilizando System. Data;TSql. Date; seleccionar i de Items como i en donde i.ModifiedTime > dateadd ('day', -10, i.ModifiedTime). 2.4.3 Plataformas Soportadas Soportadas en: SQL 2000, SQL 2005 y WinFS. 2.5 Funciones del sistema Existe un conjunto de funciones de Sistema que varían por la plataforma que residen en el espacio de nombre System. Data. TSql. System. La siguiente tabla resume esto: Las siguientes secciones proporcionan más detalles de funciones específicas. 2.5.1 Algoritmo Soundex y Diferencia La función Soundex mapea la función Soundex T-SQL y se utiliza para convertir una cadena de carácter alfa a un código de cuatro caracteres para encontrar palabras o nombres que suenen en forma similar. El primer carácter del código es el primer carácter de character_expression y el segundo en los cuatro caracteres del código, son números. Las vocales en character_expression son ignoradas a menos que sea la primera letra de la cadena de carácter. Se pueden anidar las funciones de la cadena de carácter. La sintaxis para esto es como se indica a continuación: cadena de carácter soundex ( string character_expression ) La Diferencia regresa la diferencia entre los valores SOUNDEX de dos expresiones de cadena de carácter en la forma de un entero. Esta función puede ser útil para clasificar nombres, por ejemplo, por pronunciación. La sintaxis de esto es como se indica a continuación: diferencia int ( string character_expression, string character expression ) Los siguientes son ejemplos del uso de soundex y diferencia en una solicitud. utilizando System. Data.TSql. System; // obtener la longitud de datos de DisplayName para todas las partidas seleccionar p.DisplayName, p.FullName.GivenName, p.FullName, Súmame de ofType (Items, Person) como p order by soundex (p.FullName. Súmame) desc 2.5.1.1 Plataformas Soportadas Soportada en: SQL 2000, SQL 2005 y WinFS. 2.5.2 Longitud de Datos La función Datalength se utiliza para regresar el tamaño de propiedades (como un int). Mapea la función datalength SQL. La sintaxis para esto es como se indica a continuación: Int datalength ( property ) En caso en donde la propiedad no tiene valor (por ejemplo nuil) el valor de retorno es cero *not*null. Esto en contraste con la forma en que opera la función datalength SQL. Los siguientes son ejemplos del uso de datalength en una solicitud: utilizando System. Data.TSql. System; // obtener la longitud de datos de DisplayName para todas las partidas seleccionar WinFS. Datalength (i. DisplayName) de Items como i // obtener la longitud de datos del Message Body seleccionar sum(datalength) (m. Body..Content)), m Subject de ofType (Items, Message) como m. 2.5.2.1 Plataformas Soportadas Soportadas en SQL 2005 y WinFS. 2.6 Funciones XML El soporte par solicitudes XML, se habilita a través de funciones de extensión se proporciona las siguientes funciones de extensión.

XML query (XML.xmldoc, string query ); Boolean exist(XML xmldoc, string query ); cadena de carácter valué (XML xmldoc, string query ); 2.6.1 Espacio de Nombre Estas funciones están en el espacio de nombre System. Data. TSql.XML. 2.6.2 Ejemplos Utilizando System. Data.TSql.XML; seleccionar i de Items, como i en donde Exist (\.XMLProperty; ' 11 text ()') 2.6.3 Plataforma Soportada Soportada en: SQL 2005 y WinFS. 2.7 Funciones WinFS 2.7.1 Solicitudes de Texto Completo (únicamente WinFS) WinFS debe soportar dos TVFs - Contains y FreeText (dos sobrecarga para cada una) - para búsqueda de peso completo. Estas funciones son mapeadas para funcionalidad en MSSearch: type FTFEIementType como row (Itemld Guid, Rank Int) type FTFType como Multiset<FTFEIementType>; FTFType Contains (string containsQuery); FTFType Contains (string propName, string containsQuery); FTFType FreeText (string freeTextQuery); FTFType FreeText (string propName, string freeTextQuery); Todas estas funciones regresan un multiconjunto de filas -cada una con dos campos. El campo Itemld es un Guid y el id de una Item que corresponde al predicado de texto complete. El campo Rank y el Rank para dicha partida. El resultado no es clasificado por el Rank - un order explícito debe ser utilizado por la solicitud para lograr esto. Contains Contains modela el predicado MSSearch Contains. El argumento containsQuery debe adaptarse a las sintaxis especificada por el predicado MSSearch Contains. El argumento propName debe adaptarse a la sintaxis utilizada para especificar una propiedad de búsqueda durante la instalación del esquema WinFS. FreeText FreeText modela el predicado MSSearch FreeText. El argumento freeTextQuery debe adaptarse a la sintaxis especificada por el predicado MSSearch FreeText. El argumento propName debe adaptarse a la sintaxis utilizada para especificar una propiedad de búsqueda durante la instalación del esquema WinFS. Notas eSQL no interpreta ninguno de los argumentos. Únicamente le interesa que deben ser cadenas de carácter. 2.7.1.1 Mecánicas Instalación de esquema Cuando se instala un esquema WinFS, cualesquiera propiedades de búsqueda son identificadas y almacenadas en el ensamble de cliente. La sintaxis para la especificación de propiedad es como se indica a continuación.

Procesamiento de Solicitud Tal como se menciona anteriormente, eSQL no interpreta los argumentos a estas funciones. Más específicamente, el tiempo de corrida WinFS - que analiza la solicitud - no lleva a cabo revisiones además de asegurarse de que los parámetros sean cadenas de caracteres. El proveedor WinFS es el responsable de interpretar el argumento propertyName - posiblemente como parte de SqlGen, buscando la propiedad adecuada id en el ensamble del cliente, y posteriormente traduciéndola en una invocación TVF equivalente en el almacén. El almacén TVFs tendrá signaturas que parecen: crear función FulITextSearch ( @sqlStr nvarchar (max) ) regresar @rTable table (Itemld [System.Storage.Store, 0.1,*, f45b95b0f79f4fbe] . Itemld, Rank int) crear función FulITextSearch (@propld uniqueidentifier, 5 @sqlStr nvarchar (max) ) regresar @rTable table (Itemld [System.Storage.Store, 0.1,*, f45b95b0f79f4fbe] . Itemld, Rank int) 2.7.1.2 Espacio de Nombre 10 Estas funciones están en el espacio de nombre System. Data. TSgl. WinFS. 2.7.1.3 Ejemplos Los siguientes ejemplos ilustran el uso de estas funciones: utilizando System. Data.TSql.WinFS; 15 seleccionar i.DisplayName, c.Rank de Items como i, Contains ( 'foo and bar') como c en donde i. Itemld = c.ltemld; seleccionar i.DisplayName, c.Rank de ítems como i, 20 Contains ( 'Contact.DisplayName' , 'foo y bar') como c en donde i. Itemld = c.ltemld; seleccionar i.DisplayName, c.Rank de Items como i, FreeText ( 'Treat (Contact. EAddress como UsAddress) .Zip', '12345') como c en donde i. Itemld = c . Itemld ?5 order by c.Rank desc; 2.7.1.4 Plataforma Soportada Soportada en: WinFS. 2.7.2 SumString (únicamente WinFS) El agregado SumString aggregate (que no se aun almacén UDF denominado SumString) proporciona la capacidad de concatenar los contenidos de una recolección de cadena de caracteres en una cadena de carácter simple con un delimitador. Esto es útil para un número de escenarios App que incluyen desplegar la lista "To' de los participantes de Message en un solo campo de texto. Esta extensión eSQL es una función de agregado similar a count, sum, max etc, y se puede aplicar a propiedades de cadena de carácter en InlineObjectCollections, ItemFragmentCollect'íons, ExtensionCollections y cualquier propiedad de cadena de carácter como resultado de una operación de Group. La sintaxis para este agregado es como se indica a continuación: cadena de carácter SumString (Multiset<string> col I ) en donde la recolección tiene que ser una recolección de cadena de caracteres. 2.7.2.1 Espacio de Nombre Estas funciones están en el espacio de nombre System. Data. TSql. WinFS. 2.7.2.2 Ejemplos Los siguientes son ejemplos del uso de SumString en una solicitud: utilizando System. Data.TSql.WinFS; / / concatenar la lista de ParticipantEAddress junta seleccionar SumString (m. Participante.? (ParticipantType = Sender ) .. ParticipantEAddress.Address), m.Subject de OfType (Items, Message) como m 2.7.2.3 Plataforma soportadas Soportada en: WinFS. 2.7.3 NormaHzePiqlts (únicamente WinFS) El agregado NormalizeDigits (el cual mapea a un almacén UDF denominado normalizedigits) proporciona la capacidad de clasificar cadenas de carácter en un formato similar a la clasificación de cobertura Windows. La sintaxis para esta función es como se indica a continuación: cadena de carácter NormalizeDigits (string property, int maxLength ) 2.7.3.1 Espacio de Nombre Estas funciones están en el espacio de nombre System. Data.TSql.WinFS. 2.7.3.2 Ejemplos Los siguientes son ejemplos de SumString en una solicitud: utilizar System. Data.TSql.WinFS; / / ordenar partidas utilizando la función seleccionar i.ltemld, i.NamespaceName de Items como i order by NormalizedDigits (i.NamespaceName, 4000 ) 2.7.3.3 Plataforma Soportada Soportada en: WinFS. 3 Carga de Espacio de Nombre Todos los espacios de nombre descritos en otro documento deben ser cargados automáticamente cuando se conecta a un proveedor SqlClient. No debe haber la necesidad de utiliza un inciso "using" explícito. 4 Métodos y Propiedades Calculados El lenguaje de solicitud eSQL soporta un mecanismo de extensión mediante el cual se agrega las propiedades a la clase parcial O-Space (es decir propiedades no mapeadas) que pueden ser referenciadas en las consultas. Estas propiedades requieren que una expresión eSQL esté asociada con las mismas a través de un atributo. Esta expresión posteriormente es reemplazada siempre que la propiedad sea referenciada en una solicitud. La expresión eSQL que es suministrada como referencia de otras propiedades y métodos calculados, otras propiedades mapeadas y otras funciones que son especificadas en el manifiesto del Provider. 4.1 Propiedades Calculadas El System. Data. Objects.CalculatedAttribute puede ser agregado a una Property que es definido únicamente en una clase de cliente (sin propiedad mapeada) para habilitar la referencia de la propiedad en las solicitudes. El tipo de CLR Property debe coincidir con el tipo regresado por la expresión eSQL. Si el tipo ha regresado de la expresión es un tipo nulificable, entonces la propiedad debe ser declarada como un tipo nulificable. Esta restricción es promovida por la infraestructura, y tendrá una excepción. Si el tipo de retorno de la expresión es una recolección, entonces la Property debe ser del tipo Query<T>.. La propiedad ItemSize en Item es un ejemeplo real de una propiedad calculada que existe en el Schema actual. Los siguientes son ejemplos de utilizar esta propiedad: / / Lo siguiente recupera todos los documentos que son mayores a 10k (-10000 bytes) en una carpeta en particular Quary<ltem> searcher = wd. Items. Source. Cuando ("it . ItemSize > 100000"); Esta propiedad será .arcada con el siguiente atributo: [Calculado (Expression = "System. Storage Item.GetltemSize (Itemld) " ) ] public int IteraSize {get; } La expresión anterior se refiere a una función en el manifiesto del proveedor que mapea una función en la parte del almacén. PrimaryEmailAddress es un ejemplo de una propiedad que puede ser calculada del esquema y ahora a través de esta funcionalidad puede ser anticipada y proyectaba a través de eSQL. Esta propiedad puede regresar la dirección del Email de una Person marcada con la Primary Keyword. El siguiente código, ilustra como definir esta propiedad PrimaryEmallAddress para permitir una solicitud a través del eSQL: Clase parcial pública Personltem : ... { / / Atributo de propiedad PrimaryEmaxIAddress / / el @keyword se refiere al parámetro calculado [Calculated(Expressions = ® "using System. Storage.Contacts; elemento (seleccionar valor e de this.EAddresses como e en donde e es de SmtpEmailAddress y existe (seleccionar 1 de e.Keywords en donde Value=@keyword) ) ) " ) ] [CalculatedParameter (Name-'keyword", Value-'System. Storage. Contacts. Primary") ] public SmtpEmailAddress PrimaryEmailAddress { obtener { para cada uno ( SmtpEmailAddress smtpEA in EAddresses.OfType<SmtpEmailAddress> () ) { foreach (Keyword k in smtpEA.Keywords) { si (k Valué == "System. Storage. Contacts.Primary") regresar smtpEA; } } } } } Esta propiedad posteriormente puede ser utilizada en una solicitud como se indica a continuación: QuerY<Person> searcher = wd. Partida. Source. OfType<Person> ( ) .Cuando ( " PrimaryEmailAddress .Address= ' rameshn@microsoft. Com'" ) ; Person person - searcher. GetSingle ( ) , / / Observar que el GetSingle está siendo agregado como un DCR / / La propiedad puede ser proyectada como se indica a continuación: Query<DataRecord> projection = wd. Items Source. OfType<Person> ( ). Seleccionar ( "it.DisplayName, it . PrimaryEmailAddress " ) ; / / Enumerar los resultados para cada uno (registros DataRecord en proyección) { cadena de carácter displayName = (string) record [ "DisplayName" ] ; SmtpEmailAddress PrimaryEmailAddress = {SmtpEmailAddress) record ["PrimaryEmailAddress" ] ; Notas en la expresión eSQL: • El prefino "éste" tiene que se utilizado para hacer referencia a otras Propiedades/Métodos (mapeados o calculados) en la instancia. • La expresión es únicamente validada en el tiempo de corrida. • Cualquier expresión eSQL válida puede ser suministrada, incluyendo el uso de incisos. • Los parámetros Calculados necesitan tener el prefijo @ con el objeto de reverenciarlos en la expresión. 4.2 Métodos Calculados En forma similar a las propiedades calculadas, los métodos definidos en clases parciales también pueden ser habilitados para poderse utilizar en eSQL. El System. Data. Objects.CaclulatedAttribute puede ser agregado al método en una forma similar a agregarlo a una propiedad. Las siguientes semánticas y restricciones se aplican a los métodos calculados: Los métodos genéricos (por ejemplo, X<T>) normalmente no están soportados en eSQL, es decir, el parámetro tipo genérico no será utilizado en la expresión eSQL. • La palabra clave C# que permite un número variable de parámetros para un método, no está soportado en los métodos calculados. • El polimorfismo de los métodos calculados actualmente no está soportado. • Actualmente no existe soporte para métodos calculados privados o internos definidos en forma externa, es decir, el API debe tener acceso a la propiedad/método. • En general, las invocaciones recursivas en métodos calculados no están soportadas. • La sobrecarga de métodos calculados mediante valores de parámetro (tipos) actualmente no está soportado. • El tipo de retorno del método debe coincidir con el tipo regresado por la expresión eSQL. o Si el tipo de retorno de la expresión es un tipo nulificable, entonces el método debe ser declarado como que regresa un tipo nulificable. Esta restricción es promovida por la infraestructura, y habrá una excepción. o Si el tipo de retorno de la expresión es una recolección, entonces el tipo de retorno del método debe ser del tipo Query<T>. · No están soportados los métodos de ocultamiento, especificando el operador nuevo. • No están soportados métodos virtuales. • No están soportados métodos que regresan un espacio vacío. · Los parámetros del método no requieren un prefijo con el objeto de referenciarlos en la expresión. Los siguientes son ejemplos del uso de un método calculado. El escenario aquí es generar una lista de agrupamiento tratable similar al grupo Outlook por vista de fecha, como se ilustra en la figura 3. El siguiente código encapsula esto en un método de modo que puede ser reutilizado en cualquier parte: public partial class Message : ... { / / Este método regresa los empleados de una organización / / El empleador en la expresión se refiere al empleador del parámetro del método [Calculated(Expression= ®" using System. Data.TSql.Date; Caso cuando datediff (' hour ', this.ReceivedTime, date) < 0 entonces Future ' cuando datediff ( 'hour ', this. ReceivedTime, date) < 24 entonces ' Today ' cuando datediff { 'hour' , this.ReceivedTime, date) entre 24 y 48 entonces 'Yesterday' cuando datediff ( 'hour ', this. ReceivedTime, date) entre 48 y (24 * (datepart ( 'weekday ', date) ) ) entonces datename (weekday, this. ReceivedTime) cuando datediff ( 'hour' , this. ReceivedTime, date) entre (24* (datepart ( 'weekday' ,date) ) ) y (24* (datepart ( 'weekday' ,date) ) ) + (7*24) entonces 'Last Week' cuando datediff ( 'hour ', this. ReceivedTime, date) entre (24* (datepart ( 'weekday' ,date) ) )+(7*24) y (24* (datepart ( 'weekday ', date) ) )+ (14*24) entonces 'Two Weeks Ago' cuando datediff ( 'hour ', this. ReceivedTime, date) entre (24 * (datepart ( 'weekday ', date) ) )+ (14*24) y (24* (datepart ( 'weekday ', date) ) )+ (21*24) entonces 'Three Weeks Ago' cuando datediff ( 'hour' , this .ReceivedTime/ date) entre (24* (datepart { 'weekday' ,date) ) )+ (21*24) y (24* (datepart ( 'weekday' ,date) ) )+(84*24) y datediff ( 'month' , this. ReceivedTime, date) < 2 entonces 'Last Month' además 'Older' finalizar como RelativeDate") ] cadena de carácter público GetReceivedTimeName (DateTime date) { / / La implementación de este método puede necesitar realizar una lógica similar a la expresión por consistencia } E sto poste ri o rme nte pu ed e se r uti l izad o pa ra ag ru pa r l os re s u ltad os co m o se i n d i ca a co nti n u a ci ó n : / / Créate a query over messages to group by the ReceivedTime Ñame QuerY<DataRecord> projection = context.ltems.Source..OfType<Message> ( ). Seleccionar ( " " it.Subject, it.GetReceivedTimeName (@date) como RelativeDate" , new QueryParameter ("date" , DateTime.Now) ) .GroupBy( "RelativeDate") ; // Enumérate the results foreach (DataRecord record ¡n projection) { 4.3 Atributos Calculados y CacluatedParameter El sistema System. Data. Objects.CalculatedAttribute se define como se indica a continuación espacio de nombre System. Data. Objects { { [System. Attribu teusage (AttributeTargets . Property | AttributeTarge ts. Method) ] Clase pública CalculatedAttribute : Attribute { Expresión de cadena de carácter pública {get; set;} public string Expression public CalculatedAttribute (expression string); } } Este atributo define las siguientes propiedades: • Expresión. La propiedad de expresión debe contener una expresión eSQL válida que proyecta un valor. Este vapor posiblemente se puede utilizar en otra expresión. Ver más adelante para más detalles con respecto a como especificar parámetro nombrados en expresiones. El System. Data. Objects. CalculatedParameterAttribute se define como se indica a continuación espacio de nombre System. Data. Objects { [AttributeUsage (AttributeTargets. Property ] AttributeTargets .Method, AllowMultiple = true)] clase pública CalculatedParameterAttribute : Attribute { cadena de carácter pública Ñame {get; set ;} objeto público Valué {get; set; } público CalculatedParameterAttribute(); } Este atributo define las siguientes propiedades: · Nombre. El nombre del parámetro tal como es referenciado en la propiedad de Expression del Calculated Attribute. • Valor. El valor es parámetro definido por la propiedad de nombre. Los parámetros nombrados definidos en CalculatedAttribute siguen estas semánticas. • Las referencias de los parámetros calculados deben tener un prefijo @. • El orden para definer el CalculatedParameterAttribute y CalculatedAttribute no importa. • Los nombres de parámetros deben ser únicos a través de nombres de parámetros del método y otros parámetros nombrados definidos por CalculatedParameterAttribute en el método. · Para una propiedad calculada cualesquiera parámetros nombrados en la expresión deben ser definidos mediante CalculatedParameterAttribute. • El siguiente ejemplo ilustra el uso de las clases de atributo anteriores: clase parcial pública Person : ... { / / El @ year en la expresión se refiere al año del parámetro nombrado proporcionado por: / / the CalculatedParameterAttribute [Calculated(expression=@" utilizando System. Data.TSql. Date; (@year - year (this.BirthDate) ") ] [CalculatedParameter(Name="year" ,Value=System.DateTime.Year) ] public int GetRoughAge () (...)

Claims

REIVINDICACIONES 1. Un sistema para procesar una solicitud de aplicación de datos, en donde el método comprende: una capa de servicios de objeto 210 para aceptar una solicitud, en donde la solicitud comprende una expresión de recolección en un inciso de de; una capa de proveedor de mapa 220 que suministra una pluralidad de transformaciones de mapeo para transformar la solicitud en una solicitud de base de datos; una capa puente 230 para convertir la solicitud de la base de datos en una solicitud de base de datos modificada, estando adaptada la solicitud de base de datos modificada al menos a un requerimiento de una primera base de datos 240; la primera base de datos 240 que comprende un procesador para procesar una consulta para procesar la solicitud de base de datos modificada, en donde la primera base de datos está configurada para regresar un resultado a la capa de puente.
2. El sistema tal como se describe en la reivindicación 1, caracterizado porque la solicitud comprende además una operación de ajuste seleccionada del grupo que consiste en unión, intersección y excepción, en donde la operación de ajuste opera en las recolecciones.
3. El sistema tal como se describe en la reivindicación 1, caracterizado porque la solicitud comprende además una operación de unión que opera en las recolecciones.
4. El sistema tal como se describe en la reivindicación 1, caracterizado porque la capa puente 230 está configurada para convertir la solicitud de la base de datos en cualquiera de una pluralidad de solicitudes de base de datos modificadas adaptadas a requerimientos de cualquiera de una pluralidad de las bases de datos 240.
5. Un sistema para procesar una solicitud de aplicación de datos, caracterizado porque comprende: una capa de servicios de objeto 210 para aceptar una solicitud, en donde la solicitud comprende una operación de ajuste seleccionada del grupo que consiste en unión, intersección y excepción, en donde la operación de ajuste opera en las recolecciones; una capa de proveedor de mapa 220 que suministra una pluralidad de transformaciones de mapeo para transformar la solicitud en una solicitud de base de datos; una capa puente 230 para convertir la solicitud de la base de datos en una solicitud de base de datos modificada, estando adaptada la solicitud de base de datos modificada al menos a un requerimiento de una primera base de datos 240; la primera base de datos 240 comprende un procesador para procesar la solicitud, para procesar la solicitud de la base de datos modificada, en donde la primera base de datos está configurada para regresar un resultado a la capa de puente.
6. El sistema tal como se describe en la reivindicación 5, caracterizado porque la solicitud comprende además una operación de unión que opera en las recolecciones.
7. El sistema tal como se describe en la reivindicación 5, caracterizado porque la capa puente 230 está configurada para convertir la solicitud de la base de datos en cualquiera de una pluralidad de solicitudes de base de datos modificadas adaptadas a los requerimientos de cualquier pluralidad de la base de datos 240.
8. Un sistema para procesar una solicitud de aplicación de datos, caracterizado porque comprende: una capa de servicios de objeto 210 para aceptar una operación de unión que opera en las recolecciones; una capa de proveedor de mapa 220 que suministra una pluralidad de transformaciones de mapeo para transformar la solicitud en una solicitud de base de datos; una capa puente 230 para convertir la solicitud de la base de datos en una solicitud de base de datos modificada, estando adaptada la solicitud de base de datos modificada al menos a un requerimiento de una primera base de datos 240; la primera base de datos 240 que comprende un procesador se procesamiento de solicitud para procesar la solicitud de la base de datos modificada, en donde la primera base de datos está configurada para regresar un resultado a la capa de puente 230.
9. El sistema tal como se describe en la reivindicación 8, caracterizado porque la capa puente está configurada para convertir la solicitud de la base de datos en cualquiera de una pluralidad de solicitudes de base de datos modificadas adaptadas a los requerimientos de cualquiera de una pluralidad de bases de datos.
10. Un sistema de computadora que comprende una aplicación 200 configurada para solicitar datos de la base de datos 240, en donde la solicitud genera una solicitud de acuerdo con un lenguaje de solicitud, comprendiendo el lenguaje de solicitud al menos las siguientes características: el lenguaje de solicitud permite el uso de una expresión de recolección en un inciso de de; el lenguaje de solicitud permite el uso de una operación de ajuste seleccionada del grupo que consiste en unión, intersección y excepción, en donde la operación de ajuste opera en las recolecciones; el lenguaje de solicitud permite el uso de una operación de unión que opera en las recolecciones.
11. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud requiere además que cada solicitud comprenda al menos una expresión.
12. El sistema de cómputo tal como se describe en la reivindicación 11, caracterizado porque cada expresión tiene una interpretación uniforme que no depende del contexto en el cual se utiliza.
13. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además utilizar las siguientes expresiones: 1+2 *3 "abe" fila ( 1 como a, " 2 como b) { 1, 3, 5} E1 unión de todas e2 distinto (e1 ).
14. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud considera todas las sub-solicitudes que serán sub-solicitudes de multiconjunto.
15. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque si se desea un valor escalar de una subsolicitud, el lenguaje de solicitud requiere que la aplicación proporcione un operador de elemento que opera en una recolección.
16. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además utilizar un operador de elemento para extraer un valor singleton de una recolección, y un inciso de seleccionar valué para evitar crear una envoltura de fila durante una expresión de solicitud.
17. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además el uso de un inciso de seleccionar valué para saltar una construcción de fila implícita.
18. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además utilizar un constructor de fila para construir filas arbitrarias de modo que la expresión de seleccionar valué row (e1 , e2, ...) es exactamente equivalente a la expresión seleccionar e1 , e2, ...
19. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además el uso de una expresión de solicitud que generaliza las correlaciones - izquierda en el inciso de y los trata de manera uniforme.
20. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud requiere que todas las referencias sean calificadas con un aleas de tabla.
21. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además el uso de un corte sintáctico para manejar la navegación a través de una recolección, en donde los cortes se utilizan el operador ... para permitir la proyección de una expresión procedente de una recolección, tal como "a..b" es el equivalente de "seleccionar valué t.b de a como t".
22. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además el uso de elaboración de aleas de las claves of group, y correlaciones izquierdas entre dichas claves.
23. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además el uso de dos tipos de agregados, un agregado a base de recolección que operan las recolecciones, y produce un resultado agregado, y un agregado de estilo de Lenguaje de Solicitud Estructurada (SQL), en donde el mecanismo convierte implícitamente los agregados de estilo SQL en agregados a base de recolección.
24. El sistema de cómputo tal como se describe en la reivindicación 10, caracterizado porque el lenguaje de solicitud permite además el uso de una expresión INSERT.. VALUES y la expresión no permite que se especifique una lista de columna en la expresión INSERT.. VALUES.