En los últimos años, XML ha resurgido como el nuevo estándar para la transmisión de datos, y su uso se ha vuelto más común a medida que las empresas adoptan soluciones basadas en XML. Debido a que las empresas comienzan a imponer sus estándares XML para la transmisión de todos los datos, cada vez aparecen formatos XML más complejos. Estos formatos complejos pueden incluir múltiples espacios de nombre, miles de elementos y definiciones recurrentes.
A medida que los documentos XML producidos a partir de estos formatos crecen en tamaño y complejidad, administrar este contenido se vuelve una tarea cada vez más desafiante, con información limitada en cuanto a cómo abordar este desafío. En este informe usted aprenderá a utilizar la característica XML DB d
e Oracle Database 11g a fin de administrar el contenido XML complejo así como sus ventajas sobre los productos ETL comerciales. Usted verá un ejemplo de un esquema XML complejo que muestra lo siguiente:
- Registro de un esquema XML complejo
- Inserción de archivos XML en la base de datos
- Recuperación de datos XML por medio de consultas relacionales
- Evolución en el lugar para modificaciones de esquemas XML
Asimismo, usted tendrá una visión general de las estrategias para maximizar el desempeño y rendimiento de las soluciones Oracle XML DB y las aplicaciones prácticas de formatos XML complejos.
Contexto de Oracle XML DB
Oracle XML DB es una característica de Oracle Database que ofrece una poderosa herramienta para la administración de contenido XML, con inclusión del almacenamiento, la manipulación y recuperación. Ofrece distintas opciones de almacenamiento para cumplir con los requisitos exclusivos de distintos formatos XML. Estas opciones incluyen almacenamiento no estructurado, binario y estructurado:
- No estructurado (grandes objetos de caracteres, o CLOB). Al tratar el documento como un gran objeto y almacenarlo en la base de datos, este método permite los mejores tiempos de inserción. No obstante, este método de almacenamiento también consume la mayor cantidad de espacio y tiene el peor desempeño para el acceso relacional a los datos. Esta es una solución poco práctica para administrar documentos XML grandes y complejos si se requiere el acceso relacional. El almacenamiento no estructurado puede ser una solución práctica si el espacio en disco no es un problema y el objetivo es archivar los documentos en su formato original.
- Almacenamiento Binario. Esta opción, nueva en Oracle Database 11g, almacena datos en un formato postparse binario diseñado específicamente para datos XML. Esta opción tiene varias ventajas sobre el almacenamiento no estructurado, y al ser sensible al esquema XML, permite una mejor eficiencia del espacio de disco y un mejor desempeño de las consultas. A pesar de que esta opción ofrece un desempeño increíble comparado con el del almacenamiento no estructurado, ésta no tiene el mismo desempeño de consultas que el almacenamiento estructurado. El almacenamiento binario es una buena opción cuando su desempeño para acceso relacional es aceptable. Debido a que esta opción de almacenamiento es fácil de usar, vale la pena evaluarla antes de optar por el almacenamiento estructurado.
- Almacenamiento No Estructurado. También conocido como almacenamiento basado en esquemas, esta opción utiliza un modelo de objeto relacional para almacenar documentos XML en la base de datos. Esta opción de almacenamiento es la más eficiente en términos de espacio de disco y acceso relacional. También presenta los niveles más elevados de gastos generales durante la inserción del archivo y requiere la preparación adicional para el registro del esquema. El almacenamiento estructurado es la mejor opción cuando el acceso relacional es un requisito. Para manejar archivos grandes y complejos con el fin de ofrecer acceso relacional eficiente, esta opción de almacenamiento generalmente es la mejor opción.
La percepción del tamaño y la complejidad de un documento XML pueden diferir enormemente, dependiendo de la empresa. Por un lado, para las bases de datos de procesamiento de transacciones online (OLTP) que utilizan XML para el intercambio electrónico de datos (EDI) u otro intercambio de datos transaccionales, un archivo con varias líneas podría considerarse un archivo muy extenso. Por otro lado, un depósito de datos de múltiples terabytes podría regularmente procesar documentos XML medidos en gigabytes y no considerar que un archivo sea extenso a menos que contenga millones de líneas. El mismo concepto se mantiene para la complejidad percibida de un documento XML.
A los fines de este informe, un documento se considera "complejo" si presenta las siguientes propiedades:
- Tiene un origen único, con múltiples espacios de nombre.
- Tiene definiciones XML flexibles, permitiendo grandes variaciones mientras se mantiene la validez.
- Posee referencias circulares/clínicas recurrentes.
- Posee esquemas XML no estáticos.
En este informe, los documentos XML son considerados “extensos” si poseen un solo origen y superan los 20MB. Estas propiedades incorporan ciertas consideraciones de administración y escalabilidad que deben tenerse en cuenta para obtener una solución empresarial sólida.
No hay reglas de oro para elegir la mejor opción de almacenamiento. Sobre la base de una estructura de archivos, objetivos de desempeño, recursos disponibles y el volumen de datos esperado, la mejor opción puede variar. Si usted no puede decidir cuál es la mejor opción de almacenamiento para su requerimiento particular, es conveniente probar otros formatos a fin de determinar lo que es óptimo para sus necesidades específicas.
Generalmente hablando, si usted está manejando grandes documentos y requiere acceso relacional, el almacenamiento no estructurado no es aceptable desde una perspectiva de recursos o desempeño. XML binario puede ser la solución óptima si el desempeño de consultas es aceptable para el uso comercial o si el negocio exige la aplicación de la opción con el menor tiempo de mantenimiento. No obstante, si el acceso relacional es el principal objetivo y los usuarios necesitan acceso rápido a la información contenida en un documento XML, posiblemente el almacenamiento estructurado sea la mejor opción.
Maximizar el Rendimiento con Almacenamiento Estructurado
A pesar de los gastos generales por incorporar archivos cuando se utiliza la opción de almacenamiento estructurado, usted puede reducir este costo fraccionando los grandes documentos en partes más pequeñas.
Por ejemplo, si hay un archivo XML de un solo origen de 700MB, es posible separarlo en 10 partes más pequeñas válidas con el esquema XML. Insertar 10 archivos diferentes de 70MB es mucho más rápido que insertar un solo archivo de 700MB, y el resultado es el mismo. El nivel de concurrencia debería estar determinado por la capacidad de procesamiento disponible de la base de datos. Esta estrategia aprovecha la concurrencia de la base de datos y maximiza el rendimiento.
Otra consideración para tener en cuenta cuando se utiliza Oracle XML DB es que el tiempo de inserción de un solo archivo XML generalmente está limitado por la velocidad de una única CPU. En otras palabras, tener múltiples procesadores no ayuda al rendimiento de un solo documento. Por ejemplo, considere una situación en la que se deba insertar un documento de 700MB complejo, de origen único, por medio del uso del almacenamiento basado en esquemas.
El tiempo total de inserción de este archivo podría ser de 10 minutos con un procesador 1.35GHz, ya sea que la base de datos tenga 12 ó 72 CPUs (suponiendo que al menos una CPU se encuentra disponible en cada escenario). Para aumentar el rendimiento de un solo documento XML, posiblemente necesite utilizar CPUs más rápidas. Insertar este mismo archivo cuando tiene un solo procesador de 3.4GHz podría tardar 4 minutos.
En cambio, cuando usted maneja muchos archivos XML, tener múltiples procesadores puede mejorar la concurrencia de las inserciones, lo cual mejorará el rendimiento a mayor escala. Por ejemplo, si el archivo de 700MB se divide en 10 documentos distintos de 70MB, el tiempo de inserción de cada documento de 70MB puede ser menor a un minuto si usted utiliza la base de datos con los procesadores 1.35GHz. Si la CPU está disponible, los 10 documentos pueden ser insertados simultáneamente en la base de datos. Esta estrategia da como resultado un tiempo de inserción total de alrededor de un minuto para insertar todo el documento de 700MB.
Desafortunadamente, calcular estas comparaciones no es ciencia exacta. Cada base de datos puede desempeñarse de manera diferente, dependiendo de varios factores, con inclusión del sistema operativo, la capacidad de procesamiento disponible, la memoria y la definición de esquemas. La mejor manera de optimizar el desempeño en su entorno es implementando estas estrategias y determinando los beneficios de cada una de ellas.
Productos ETL de Oracle XML DB vs. Listos para la Venta (COTS)
Varias herramientas comerciales de extracción, transformación y carga (ETL) están disponibles para cargar información de archivos en la base de datos. Estas herramientas generalmente presentan un solo front end con capacidad drag-and-drop y pueden ocultar la complejidad del verdadero proceso. Cuando usted crea un proceso de carga XML en una herramienta ETL comercial, es necesario definir los campos que deben extraerse. Si no especifica un determinado XPath, los datos no serán recopilados del documento.
En caso de documentos XMl complejos, la ventaja de Oracle XML DB es que obtiene una visión de los documentos centrada en la base de datos y analiza cada documento en un modelo de objeto relacional. Cuando el archivo se inserta exitosamente en la base de datos, se puede acceder a toda la información contenida dentro de ese archivo sin necesidad de ser nuevamente analizada.
Uno de los mejores beneficios de Oracle XML DB es que es una característica estándar de Oracle Database y no requiere licencia adicional. Pero si las tarifas de las licencias no fueran una preocupación para la empresa, ¿por qué usaría Oracle XML DB para su administración de contenido XML en lugar de la herramienta de una empresa que utilice ETL como función principal? Para comprender la respuesta, es necesario comprender cómo la tecnología de Oracle XML DB cumple con los requisitos exclusivos para la administración de XML complejo.
Los Desafíos del Contenido XML Complejo
Cuando el contenido XML es flexible, frecuentemente cambiante, recurrente y muy extenso, un desarrollador sin dudas encontrará ciertos desafíos que podrían no presentarse en los formatos más simples. Una de las posibilidades que podría presentarse con un documento XML complejo es que su esquema XML sea muy grande y permitir gran cantidad de flexibilidad mientras se mantiene válido. El uso de esquemas XML flexibles es una estrategia común para respaldar los estándares de todo el sector mientras se cumple con los requisitos específicos de la empresa.
Por ejemplo, se adopta un esquema XML como estándar para tres empresas. Además de los elementos estándar o compartidos, este esquema XML deberá incluir todas las definiciones específicas de la empresa para cada una de las empresas. Para respaldar este requerimiento, el esquema XML se diseña con gran flexibilidad para uso de elementos de contenido genérico que hagan referencia a todos los elementos específicos de la empresa posibles y que permitan que la mayoría de las referencias de elementos se produzcan 0 o más veces.
Como resultado, los documentos con elementos completamente diferentes son válidos con el mismo esquema XML. Desde una perspectiva de desarrollo, esta flexibilidad dificulta la escritura de análisis XML para extraer los datos necesarios, debido a que el surgimiento de elementos es difícil de predecir. Como las herramientas COTS ETL y los análisis personalizados requieren un XPath específico para la extracción de datos, cada XPath posible podría necesitar ser controlado para garantizar la captura de toda la información del documento.
Esta no es una solución práctica ya que existe una cantidad exponencial de posibles XPaths. Asimismo, si existen referencias recurrentes o cíclicas en el esquema, ellas son infinitas. Cuando se detectan datos que no han sido capturados, la única resolución es volver a analizar todo el archivo, una operación costosa que debería evitarse, de ser posible.
Tenga en cuenta el siguiente esquema XML (preste atención a las referencias cíclicas y a la flexibilidad del esquema que resulta de los elementos genéricos):
startData.xsd
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:bc="startData.xsd" xmlns:xn="standardData.xsd"
xmlns:es="CompanySpecific.1.0.xsd"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xdb="http://xmlns.oracle.com/xdb"
targetNamespace="startData.xsd"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<import namespace="standardData.xsd" schemaLocation="standardData.xsd"/>
<import namespace="CompanySpecific.1.0.xsd"
schemaLocation="CompanySpecific.1.0.xsd"/>
<element name="rootElement" xdb:defaultTable="XML_DEFAULT">
<complexType>
<sequence>
<element name="fileHeader">
<complexType>
<attribute name="fileFormat" type="string"
use="required"/>
<attribute name="companyName" type="string"
use="optional"/>
</complexType>
</element>
<element name="fileData" maxOccurs="unbounded">
<complexType>
<choice>
<element ref="xn:childContainer"
maxOccurs="unbounded"/>
<element ref="xn:salesInformation"
maxOccurs="unbounded"/>
</choice>
</complexType>
</element>
<element name="fileFooter">
<complexType>
<attribute name="timeStamp" type="string"
use="required"/>
</complexType>
</element>
</sequence>
</complexType>
</element>
</schema>
standardData.xsd
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xn="standardData.xsd"
targetNamespace="standardData.xsd"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:cs="CompanySpecific.1.0.xsd" >
<import namespace="CompanySpecific.1.0.xsd"
schemaLocation="CompanySpecific.1.0.xsd"/>
<element name="childContainer">
<complexType>
<sequence>
<element name="attributes" minOccurs="0">
<complexType>
<all>
<element name="childLabel" minOccurs="0"/>
<element name="childType" minOccurs="0"/>
</all>
</complexType>
</element>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="xn:childContainer"/>
<element ref="xn:CompanySpecificContainer"/>
<element ref="xn:salesInformation"/>
</choice>
</sequence>
</complexType>
</element>
<element name="salesInformation">
<complexType>
<sequence>
<element name="storeNumber" type="string" minOccurs="0"/>
<element name="orderNumber" type="string" minOccurs="0"/>
<element name="salesDate" type="string" minOccurs="0"/>
<element name="product" type="string" minOccurs="0"/>
<element name="quantity" type="string" minOccurs="0"/>
<element name="price" type="string" minOccurs="0"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="xn:childContainer"/>
</choice>
</sequence>
</complexType>
</element>
<element name="CompanySpecificContainer">
<complexType>
<sequence>
<element name="attributes" minOccurs="0">
<complexType>
<all>
<element name="csDataType" minOccurs="0"/>
<element name="csDataFormat" minOccurs="0"/>
<element ref="cs:csStore" minOccurs="0"/>
<element ref="cs:csProduct" minOccurs="0"/>
</all>
</complexType>
</element>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="xn:CompanySpecificContainer"/>
</choice>
</sequence>
</complexType>
</element>
</schema>
CompanySpecific.1.0.xsd
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:cs="CompanySpecific.1.0.xsd"
targetNamespace="CompanySpecific.1.0.xsd"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<element name="csStore">
<complexType>
<sequence>
<element name="label" type="string" minOccurs="0"/>
<element name="name" type="string" minOccurs="0"/>
<element name="value" type="string" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="csProduct">
<complexType>
<sequence>
<element name="label" type="string" minOccurs="0"/>
<element name="name" type="string" minOccurs="0"/>
<element name="value" type="string" minOccurs="0"/>
</sequence>
</complexType>
</element>
</schema>
Este esquema XML podría utilizarse como estándar del sector para transmitir información de inventario y ventas. Tenga en cuenta que en el espacio de nombre standardData.xsd, tanto el elemento childContainer como el elemento companySpecificContainer actúan opcionalmente como autoreferencia. En esta definición particular, este diseño permite que cada empresa decida la granularidad de sus datos utilizando la relación principal/secundario. Este esquema también le da a cada empresa la opción de incluir datos de inventarios, datos de venta, o ambos. Además permite a cada empresa incluir o no incluir más locales, productos y ventas, sobre la base de sus necesidades individuales pero dentro del mismo formato flexible.
Por ejemplo, si una empresa hipotética ABC quiere incorporar datos de ventas e inventario de múltiples locales, podría usar una recopilación de los elementos CompanySpecificContainer para identificar cada local (principal) y una recopilación de elementos CompanySpecificContainer para identificar los productos (secundario) para cada local.
Un documento válido para ABC podría ser:
CompanyABC.xml
<?xml version="1.0"?>
<rootElement xmlns="startData.xsd" xmlns:xn="standardData.xsd"
xmlns:cs="CompanySpecific.1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<fileHeader fileFormat="v1.0" companyName="CompanyABC"/>
<fileData>
<xn:childContainer>
<xn:attributes>
<xn:childLabel>Store 0001 Inventory</xn:childLabel>
<xn:childType>Stock</xn:childType>
</xn:attributes>
<xn:CompanySpecificContainer>
<xn:attributes>
<xn:csDataType>csStore</xn:csDataType>
<xn:csDataFormat>CompanySpecific.1.0</xn:csDataFormat>
<cs:csStore>
<cs:label>Store 0001</cs:label>
<cs:name>Product 1</cs:name>
<cs:value>In Stock</cs:value>
</cs:csStore>
</xn:attributes>
<xn:CompanySpecificContainer>
<xn:attributes>
<xn:csDataType>csProduct</xn:csDataType>
<xn:csDataFormat>CompanySpecific.1.0</xn:csDataFormat>
<cs:csProduct>
<cs:label>Product 1</cs:label>
<cs:name>Quantity</cs:name>
<cs:value>10</cs:value>
</cs:csProduct>
</xn:attributes>
</xn:CompanySpecificContainer>
</xn:CompanySpecificContainer>
<xn:salesInformation>
<xn:storeNumber>Store 0001</xn:storeNumber>
<xn:orderNumber>12345</xn:orderNumber>
<xn:salesDate>20-SEP-2007</xn:salesDate>
<xn:product>Product 1</xn:product>
<xn:quantity>1</xn:quantity>
<xn:price>110.00</xn:price>
</xn:salesInformation>
</xn:childContainer>
</fileData>
<fileFooter timeStamp="20-SEP-2007"/>
</rootElement>
No obstante, si otra empresa, XYZ, tuviera un solo local y quisiera incorporar solo la información de ventas estándar de sus archivos, ésta omitiría el elemento childContainer e incluiría una recopilación de elementos salesInformation. Un documento válido de XYZ que describa solo la información de ventas estándar sería el siguiente:
CompanyXYZ.xml
<?xml version="1.0"?>
<rootElement xmlns="startData.xsd" xmlns:xn="standardData.xsd"
xmlns:cs="CompanySpecific.1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<fileHeader fileFormat="v1.0" companyName="CompanyXYZ"/>
<fileData>
<xn:salesInformation>
<xn:storeNumber>Store 0001</xn:storeNumber>
<xn:orderNumber>12345</xn:orderNumber>
<xn:salesDate>20-SEP-2007</xn:salesDate>
<xn:product>Product 1</xn:product>
<xn:quantity>1</xn:quantity>
<xn:price>110.00</xn:price>
</xn:salesInformation>
</fileData>
<fileFooter timeStamp="20-SEP-2007"/>
</rootElement>
Estos documentos son muy distintos, pero ambos son válidos en el esquema XML. Este diseño facilita el uso de estándares para todo el sector de diferentes empresas, con un formato único y flexible en el esquema XML. No obstante, el uso de referencias recurrentes para elementos de contenido genérico permite a cada empresa decidir la cantidad de detalles a incluir mientras se mantiene el cumplimiento con el esquema XML. Por ejemplo, un solo XPath para la extracción de datos CompanyABC.xml sería
'/rootElement/fileData/xn:childContainer/xn:CompanySpecificContainer/
xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:value'
Sin embargo, si esta empresa desea incluir los datos almacenados con mayor granularidad, podría incluir otro elemento secundario para los sublocales, como por ejemplo: '/rootElement/fileData/xn:childContainer/xn:CompanySpecificContainer/
xn:CompanySpecificContainer/
xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:value'
El diseño de este esquema XML permite enriquecer los archivos con el contenido determinado por cada empresa. Al utilizar las referencias opcionales y los elementos de contenido genérico, cada documento comienza a parecerse a una base de datos. Debido a la imprevisibilidad de cada archivo, administrar este XML con código personalizado o una herramienta COTS ETL implicaría un gran esfuerzo de desarrollo que requeriría el continuo mantenimiento y soporte. Si alguna de las empresas que utilizan este esquema XML incluyera un nuevo XPath, el código de extracción debería ser modificado para capturar estos datos. Todo archivo analizado sin los XPath actualizados debería ser reprocesado por completo. Este ejemplo muestra los desafíos sustanciales de los esquemas XML completos y las dificultades de los desarrolladores que administran dicho contenido.
La Solución Oracle XML DB
Este problema con el mapeo XPath, como se muestra en el ejemplo de arriba, no existe con Oracle XML DB, debido a que todo el archivo se almacena en la base de datos. Tan pronto como el documento es insertado, el contenido del documento queda inmediatamente a disposición para posibles consultas. Independientemente de la flexibilidad del esquema XML, se puede acceder a la información contenida en el documento con el XPath adecuado. Esto brinda una ventaja incomparable que maximiza la disponibilidad y minimiza el costo de mantenimiento.
Para implementar la solución XML DB, comience registrando el esquema XML (los documentos y archivos de definición se encuentran en un directorio denominado XML_TEST):
begin
DBMS_XMLSCHEMA.REGISTERSCHEMA(
schemaurl => 'CompanySpecific.1.0.xsd',
schemadoc => BFILENAME ('XML_TEST','CompanySpecific.1.0.xsd')
);
DBMS_XMLSCHEMA.REGISTERSCHEMA(
schemaurl => 'standardData.xsd',
schemadoc => BFILENAME ('XML_TEST','standardData.xsd')
);
DBMS_XMLSCHEMA.REGISTERSCHEMA(
schemaurl => 'startData.xsd',
schemadoc => BFILENAME ('XML_TEST','startData.xsd')
);
end;
/
Ahora que usted ha creado una estructura de objeto relacional para nuestro esquema XML, usted está listo para insertar archivos XML en la tabla por defecto (especificada en la anotación del elemento de origen).
insert into XML_DEFAULT values (XMLTYPE(BFILENAME
('XML_TEST','CompanyABC.xml'),nls_charset_id('AL32UTF8')));
/
El archivo es exitosamente insertado en una fracción de segundos. Los datos están inmediatamente disponibles para el acceso relacional. Aquí hay un ejemplo de un acceso de consulta que describe el actual inventario:
SELECT extractValue(object_value,'/rootElement/fileFooter/@timeStamp')
start_date,
extractValue(object_value,'/rootElement/fileHeader/@companyName')
companyName,
extractValue(object_value,'/rootElement/fileHeader/@fileFormat')
fileFormat,
extractValue(value(b),
'/xn:childContainer/xn:attributes/xn:childLabel',
'xmlns:xn="standardData.xsd"') childLabel,
extractValue(value(b),
'/xn:childContainer/xn:attributes/xn:childType',
'xmlns:xn="standardData.xsd"') childType,
extractValue(value(c),
'/xn:CompanySpecificContainer/xn:attributes/xn:csDataType',
'xmlns:xn="standardData.xsd"') csDataType,
extractValue(value(c),
'/xn:CompanySpecificContainer/xn:attributes/xn:csDataFormat',
'xmlns:xn="standardData.xsd"') csDataFormat,
extractValue(value(c),
'/xn:CompanySpecificContainer/xn:attributes/cs:csStore/cs:label',
'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
csStoreLabel,
extractValue(value(c),
'/xn:CompanySpecificContainer/xn:attributes/cs:csStore/cs:name',
'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
csStoreName,
extractValue(value(c),
'/xn:CompanySpecificContainer/xn:attributes/cs:csStore/cs:value',
'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
csStoreValue,
extractValue(value(c),
'/xn:CompanySpecificContainer/xn:CompanySpecificContainer/xn:attributes/
xn:csDataType',
'xmlns:xn="standardData.xsd"') csDataTypeL2,
extractValue(value(d),
'/xn:CompanySpecificContainer/xn:attributes/xn:csDataFormat',
'xmlns:xn="standardData.xsd"') csDataFormatL2,
extractValue(value(d),
'/xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:label',
'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
csProductLabel,
extractValue(value(d),
'/xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:name',
'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
csProductName,
extractValue(value(d),
'/xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:value',
'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
csProductValue
from
XML_DEFAULT a
,TABLE(XMLSequence(Extract(object_value,
'/rootElement/fileData/xn:childContainer',
'xmlns:xn="standardData.xsd" xmlns="startData.xsd"'))) b
,TABLE(XMLSequence(Extract(value(b),
'/xn:childContainer/xn:CompanySpecificContainer',
'xmlns:xn="standardData.xsd"'))) c
,TABLE(XMLSequence(Extract(value(c),
'/xn:CompanySpecificContainer/xn:CompanySpecificContainer',
'xmlns:xn="standardData.xsd"'))) d
/
...
snipped...
Esta solución permite la administración de cualquier documento que concuerde con la definición de esquema XML. La visión de los documentos XML centrada en la base de datos de Oracle XML DB permite la utilización de documentos XML valiosos en contenido mientras se brinda un nivel de abstracción de las complejidades de desarrollo que sería inevitable con cualquier otra tecnología ETL.
Este ejemplo muestra las incomparables capacidades XML de almacenamiento y recuperación de Oracle XML DB. No obstante, el esquema XML completo también se caracteriza por tener cambios frecuentes en la definición del esquema XML. ¿Cómo Oracle XML DB facilita los cambios en el esquema XML?
Administración de Cambios en el Esquema XML
En el ejemplo anterior, la flexibilidad del esquema ha sido suministrada mediante el uso de elementos de contenedores genéricos y las referencias opcionales de todos los elementos específicos de la empresa. A pesar de que este diseño ofrece flexibilidad sustancial dentro del esquema XML, existe la posibilidad de realizar cambios en el espacio de nombre CompanySpecific.1.0.xsd si las empresas individuales eligen incluir datos adicionales en sus archivos.
Los cambios en las definiciones del esquema siempre han sido problemáticos para las soluciones basadas en XML. Generalmente es así porque se supone que un esquema XML debe ser utilizado para validar un documento XML. Si el documento contiene elementos no definidos en el esquema, el documento no es válido.
En el pasado, esto ha sido una debilidad de Oracle XML DB, ya que los cambios realizados en esquemas XML registrados requerían una operación costosa y compleja utilizando el procedimiento copyEvolve. Este procedimiento bloquea los recursos, crea tablas temporarias, traslada todos los datos desde la tabla XML de este esquema a las tablas temporarias, aplica cambios de esquemas, y luego devuelve los datos a la tabla XML. Cuantos más datos haya en la tabla XML, más larga y costosa será esta operación. Dependiendo del tamaño de la tabla, podría llevar horas completar una evolución del esquema para incorporar un solo elemento o atributo. Con respecto a XML complejo, este procedimiento no era una solución adecuada para administrar los cambios de esquema.
Para abordar esta limitación, Oracle ha introducido en Oracle XML DB 11g un nuevo procedimiento denominado inPlaceEvolve, el cual permite realizar las mismas modificaciones de esquema en una operación online que no requiera el movimiento de datos. En cambio, este procedimiento modifica los objetos de base de datos creados durante el registro de esquemas mientras los datos relacionados siguen disponibles. Esta mejora es fundamental para abordar los frecuentes cambios de definición comunes en esquemas XML complejos.
Al utilizar nuestro ejemplo anterior, considere una situación en la que se agrega un elemento adicional a la definición csProduct:
CompanySpecific.1.1.xsd
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:cs="CompanySpecific.1.0.xsd"
targetNamespace="CompanySpecific.1.0.xsd" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<element name="csStore">
<complexType>
<sequence>
<element name="label" type="string" minOccurs="0"/>
<element name="name" type="string" minOccurs="0"/>
<element name="value" type="string" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="csProduct">
<complexType>
<sequence>
<element name="label" type="string" minOccurs="0"/>
<element name="name" type="string" minOccurs="0"/>
<element name="value" type="string" minOccurs="0"/>
<element name="class" type="string" minOccurs="0"/>
</sequence>
</complexType>
</element>
</schema>
Con Oracle XML DB 11g, esta modificación es rápida y requiere recursos mínimos. Este nuevo procedimiento requiere que el esquema URL y un documento XMLType (XMLDiff) se ajusten al esquema xdiff XML. El documento XMLDiff es un documento especialmente formateado que refleja los cambios en el esquema XML. En lugar de tener que crear manualmente el documento XMLDiff, éste puede realizarse automáticamente con la función xmldiff en Oracle Database.
Primero, cree un nuevo archivo de esquema con la definición de esquema XML actualizada CompanySpecific.1.1.xsd. Luego utilice la función xmldiff de Oracle Database con el antiguo esquema como primer parámetro y el nuevo esquema como segundo parámetro:
var oldSchemaDoc clob;
var newSchemaDoc clob;
begin
:oldSchemaDoc := xmltype(bfilename('XML_TEST','CompanySpecific.1.0.xsd'),
nls_charset_id('AL32UTF8') ).getClobVal();
:newSchemaDoc := xmltype(bfilename('XML_TEST','CompanySpecific.1.1.xsd'),
nls_charset_id('AL32UTF8') ).getClobVal();
end;
/
Usted puede ver el documento XMLDiff utilizando select xmldiff(xmltype(:oldSchemaDoc),xmltype(:newSchemaDoc)).getClobVal()
from dual;
/
Por razones de simplicidad, utilice una variable CLOB para almacenar el documento XMLDiff. var diffXMLDoc clob;
begin
select xmldiff(xmltype(:oldSchemaDoc),xmltype(:newSchemaDoc)).getClobVal()
into :diffXMLDoc from dual;
end;
/
Ahora que el documento XMLDiff está disponible, el procedimiento inPlaceEvolve puede utilizarse para modificar el esquema XML online. SQL>alter session set events='31150 trace name context forever, level 0x200000';
Session altered.
SQL>
SQL> BEGIN
2 DBMS_XMLSCHEMA.inPlaceEvolve('CompanySpecific.1.0.xsd',xmltype(:diffXMLDoc));
3 END;
4 /
PL/SQL procedure successfully completed.
Un análisis del archivo de rastreo muestra que el tipo de base de datos que representa al elemento complejo modificado fue alterado para incluir al nuevo elemento: change to ct sqltype = csProduct1046_T
------------ QMTS Executing SQL ------------
ALTER TYPE "XMLTEST"."csProduct1046_T"
ADD ATTRIBUTE "class" VARCHAR2(4000 CHAR)
CASCADE NOT INCLUDING TABLE DATA
/
--------------------------------------------
La incorporación de esta nueva característica facilita la administración efectiva de los cambios en los esquemas XML, aún con una gran cantidad de volumen de documentos, sin requerir la aparición de una ventana de no disponibilidad durante la evolución del esquema. Esta es una importante mejora que optimiza la viabilidad de utilizar Oracle XML DB para las soluciones de grandes empresas.
Aplicaciones Prácticas
Oracle XML DB 11g ofrece una solución completa y eficiente para la administración de contenido que es mucho más útil y práctica que cualquier otra alternativa. Al tener una visión de cada documento centrada en la base de datos, Oracle XML DB ofrece un método innovador y avanzado para almacenar y recuperar el contenido XML. Las distintas opciones de almacenamiento brindan la capacidad de administrar eficazmente todos los documentos, independientemente del tamaño y la complejidad. La nueva característica para modificar eficazmente las definiciones del esquema XML hace que Oracle XML DB sea la solución ideal para el contenido frecuentemente cambiante. Estas características cumplen con los desafíos de administración de contenido XML complejo y brinda una solución que merece ser seriamente considerada por todas las empresas.
A pesar de que el uso de XML complejo descrito en este informe podría parecer bastante complicado, surge como el estándar de varias industrias. Por ejemplo, en el sector de telecomunicaciones, las empresas ya están utilizando esquemas XML similares a los demostrados en este informe para distribuir métricas de transmisión (vea 3GPP). Considerando el gran valor y la flexibilidad que XML complejo ofrece y las incomparables capacidades de Oracle XML DB para administrar eficazmente este contenido, es posible que el uso de XML se vuelva más frecuente a medida que más responsables de la toma de decisiones tomen conciencia del potencial de Oracle XML DB 11g.
Fuente: Web Oficial de Oracle
