Relaciones Anidadas

6.1 RELACIONES ANIDADAS

El modelo relacional anidado es una extensión del modelo relacional en la que los dominios pueden ser atómicos o de relación. Por tanto, el valor de las tuplas de los atributos puede ser una relación, y las relaciones pueden guardarse en otras relaciones. Los objetos complejos, por tanto, pueden representarse mediante una única tupla de las relaciones anidadas. Si se consideran las tuplas de las relaciones anidadas como elementos de datos, se tiene una correspondencia uno a uno entre los elementos de datos y los objetos de la vista de la base de datos del usuario.

6.2 TIPOS COMPLEJOS

La compatibilidad de tipos complejos en WCF RIA Services proporciona un medio para encapsular un conjunto de propiedades de entidad en una sola propiedad (compleja). Estos tipos se pueden utilizar para simplificar una entidad cuando contiene un subconjunto concreto de propiedades relacionadas. Los tipos complejos pueden ser reutilizados por otra entidad (diferente) que comparte el mismo subconjunto de propiedades. Un ejemplo común de un tipo complejo es un elemento Address, que reúne las propiedades de entidad necesarias para especificar una dirección. El conjunto de propiedades de un tipo Address puede incluir, por ejemplo, las propiedades de entidad StreetAddress,City, StateProvince, PostalCode y Country. Este tipo complejo pueden utilizarlo las entidades Customer y Contactproporcionadas que comparten este conjunto de propiedades. Eso hace que, una vez definido, el tipo Addresspersonalizado se pueda utilizar como una propiedad de entidad en otras entidades.

Un tipo complejo es una plantilla para definir propiedades estructuradas avanzadas en tipos de entidad o en otras entidades complejas, ya que un tipo complejo puede contener propiedades que son también de un tipo complejo. Un tipo complejo debe especificar un nombre que es único en su espacio de nombres y, opcionalmente, contiene datos en forma de una o más propiedades. Los tipos complejos solo pueden existir como propiedades en tipos de entidad u otros tipos complejos, ya que no tienen identidades y, por lo tanto, no pueden existir independientemente. Son tipos genuinos y, por consiguiente, se pueden crear instancias de ellos y utilizarse en código, pero no se pueden consultar directamente ni conservar en una base de datos, como sí se puede con los tipos de entidad. Los tipos complejos también se diferencian de las entidades en que no pueden participar en una asociación. De ahí que no se puedan definir propiedades de navegación en tipos complejos mientras que sí se puede realizar esta acción en tipos de entidad.

Se ha agregado compatibilidad con tipos complejos que no son de entidad en WCF RIA Services V1.0 SP1. Concretamente, se proporciona compatibilidad con la generación de código de tipos complejos que derivan de la clase base ComplexObject. La compatibilidad con la generación de proxies de clientes es igual de avanzada que la compatibilidad con entidades de RIA Services . También se proporciona compatibilidad de metadatos en el mismo nivel que entidades, como validación profunda, seguimiento de cambios, sesiones de edición y parámetros de tipo complejo. Esto significa que los tipos personalizados, como Address, se pueden utilizar ahora no solo como propiedades de entidad sino también como parámetros o como valores devueltos para métodos de servicio de dominio.

La representación XML del tipo complejo

RIA Services usa el lenguaje de definición de esquemas conceptuales (CSDL) para especificar modelos de datos. Es un lenguaje basado en XML que describe las entidades, las relaciones y las funciones que conforman un modelo conceptual de una aplicación controlada por datos. La especificación del nuevo tipo MailAddress está en la sección CSDL del código XML.

Para tener acceso a él, seleccione AdventureWorksModel.edmx en el Explorador de soluciones, haga clic con el botón secundario y seleccione Abrir con y, a continuación, elija Editor XML (texto). Visual Studio 2010 tendrá que cerrar la Vista de diseño del modelo de datos para abrir la representación XML; por lo tanto, seleccione Sí para aprobar esta acción. Observe que la nueva propiedad MailAddress está especificada en el elemento <EntityType Name=”Address”>:

<Property Name="MailAddress" Type="AdventureWorksLTModel.MailAddress" Nullable="false" />

La propiedad MailAddress está definida en su propio elemento debajo de las secciones donde están definidas las asociaciones.

<ComplexType Name="MailAddress">

<Property Type="String" Name="AddressLine1" Nullable="false" MaxLength="60" FixedLength="false" Unicode="true" />

<Property Type="String" Name="AddressLine2" MaxLength="60" FixedLength="false" Unicode="true" />

<Property Type="String" Name="City" Nullable="false" MaxLength="30" FixedLength="false" Unicode="true" />

<Property Type="String" Name="StateProvince" Nullable="false" MaxLength="50" FixedLength="false" Unicode="true" />

<Property Type="String" Name="CountryRegion" Nullable="false" MaxLength="50" FixedLength="false" Unicode="true" />

<Property Type="String" Name="PostalCode" Nullable="false" MaxLength="15" FixedLength="false" Unicode="true" />

</ComplexType>

Observe que no hay ningún elemento <Key> dentro de un elemento <ComplexType> como sí lo hay en un elemento .

Reutilizar un tipo complejo en otra entidad

Si se tuviera un tipo de entidad Manufacturer que contuviera el mismo conjunto de propiedades de dirección, se podrían encapsular estas en el tipo complejo . Use Refactorizar en nuevo tipo complejo como ya hizo para crear el tipo complejo y, a continuación, cambie el tipo y el nombre en la ventana Propiedades. Los campos señalarán sus entidades respectivas. Por ejemplo, el campo City para el elemento MailAddress de la entidad Address se asignará aAddress.City, mientras que este campo se asignará a Manufacturer.City para el tipo de entidad Manufacturer. Use la tabla Detalles de la asignación para asegurarse de que las propiedades se asignen de nuevo a las columnas correctas de la base de datos.

6.3 HERENCIA

La herencia es una herramienta muy potente para estructurar datos relacionados mediante generalización y para evitar repetir código y datos.

HERENCIA DE TIPO

La herencia de tipos surge por la posibilidad de definir tipos que sean subtipos de otros supertipos. Aparte de que los subtipos definen sus propios atributos y sus métodos, los subtipos heredan los atributos y los métodos definidos para sus supertipos. Los subtipos son capaces de redefinir los métodos que heredan, que es lo que conocemos como polimorfismo.

Por ejemplo, desde el objeto general supertipo TIPO_PERSONA podemos definir el subtipo TIPO_EMPLEADO que heredarán las características de su supertipo TIPO_PERSONA. El tipo objeto especializado TIPO_EMPLEADO pueden tener atributos adicionales o pueden redefinir métodos del objeto padre TIPO_PERSONA extendiendo la funcionalidad de sus tipos objeto.

Para especificar una herencia a nivel de tipo, se usa la palabra clave under en la definición del tipo derivado.

Ejemplo:

create type Persona....

create type Estudiante under Persona ...

Los métodos también se heredan, pero se pueden sobreescribir mediante overriding method en vez de method.

HERENCIA DE TABLAS

La herencia de tablas en SQL1999 corresponde con el concepto de generalización del modelo

E/R. Por tanto, cada atributo presente en una supertabla debe estar también presente en las subtablas.

Requerimientos de consistencia en SQL1999:

Para que se considere que hay consistencia, en una herencia por tablas, se deben cumplir las siguientes restricciones:

· Cada tupla de la supertabla puede corresponder a lo sumo a una tupla de cada una de sus tablas inmediatas.

· Una tupla de una subtabla no puede corresponder a la misma tupla de la supertabla que otra tupla de otra subtabla.

Las subtablas pueden implementarse de 2 formas distintas, cada una con sus ventajas y desventajas:

· Cada subtabla almacena la clave primaria de la tupla padre y los atributos derivados, de esta forma, para acceder a los datos de un objeto, se debe consultar la subclase y la clase padre correspondiente.

· Cada subtabla almacena todos sus atributos heredados y definidos localmente. Cuando se inserta una tupla se almacena solo en la tabla a la que pertenece y su presencia se infiere a las supertablas.

Solapamiento de subtablas.

Cuando una entidad puede pertenecer a varios subtipos, si se realiza la herencia por tipos habría que generar un subtipo por cada combinación posible. Este problema se puede solucionar con herencia por tablas, de esta forma, se guarda la tupla en la super tabla y se generan tantas tuplas relacionadas en las subtablas como a subtipos pertenezca.

Esta solución no cumple la segunda restricción de consistencia,

...