DB Avanzadas

Modelo de almacenamiento de 1er nivel
Modelo orientado a objetos (OODM):

Modelo de datos (lógico) que captura la semántica de los objetos soportada en
programación orientada a objetos
Base de datos orientada a objetos (OODB)
Colección persistente y compartible de objetos definidos en una OODM
Sistema gestor de base de datos orientado a objetos (OODBMS)
Administrador de un OODB
Tipos de persistencia en OODBMS
Clases, creación, marcas, alcance dentro de los procedimientos / de los programas,
entre programas
Tipos de datos complejos
Son los datos que están compuestos de otro tipo de datos existentes
Datos semi-estructurados XML
Datos que pueden ser irregulares o incompletos, su estructura puede cambiar
rápidamente, tiene una estructura que puede ser no rígida, regular o completa. Los
datos no conforman un esquema fijo.
Elementos que puede encontrar en un documento XML
Elemento raíz, atributos, comentarios, instrucciones.
Ventajas de XML
Simplicidad / extensible / reutilizable / estándar abierto / nuevas oportunidades
Tecnologías relacionadas con XML
SAX, XSL / XSLT, XPath, XPointer, XLink, XHTPIL?, SOAP, WSDL
Qué es un Datawarehouse
Es una colección orientada a sujetos de datos integrados desde varias DB
operacionales. Sirve para toma de decisiones.
Arquitectura del DWH
OLTP: On-Line Transactional Processing

son bases de datos orientadas al procesamiento de transacciones. Una transacción
genera un proceso atómico (que debe ser validado con un commit, o invalidado con
un rollback), y que puede involucrar operaciones de inserción, modificación y
borrado de datos. El proceso transaccional es típico de las bases de datos
operacionales.
OLAP: On-Line Analytical Processing
son bases de datos orientadas al procesamiento analítico. Este análisis suele
implicar, generalmente, la lectura de grandes cantidades de datos para llegar a
extraer algún tipo de información útil: tendencias de ventas, patrones de
comportamiento de los consumidores, elaboración de informes complejos… etc. Este
sistema es típico de los datamarts.
BASES DE DATOS DISTRIBUIDAS
Base de datos (DB)
Es un conjunto de datos que se encuentran en un almacenamiento de computadora
, típicamente están organizadas en registros.
Sistema gestor de base de datos (DBMS)
Es un software que administra (gestiona) los registros de una DB
Bases de datos distribuidas (DDBS)
Colección de múltiples bases de datos distribuidas lógicamente interrelacionadas
sobre una red, se tiene transparencia en la replicación, fragmentación y en la red.
Factores que impiden el uso de DDBS
Complejidad, costo, seguridad
Transacciones distribuidas
Flat - solo punto de inicio / fin
Nested – permite incluir otras transacciones
Propiedades de las transacciones distribuidas
Atomicidad – aislamiento – consistencia – durabilidad
Diseño de una DDBS
2 estrategias: Top-down desing process,, Bottom Desing Process
Fragmentación
Descomposición de una relación en fragmentos c/u tratado como una unidad permite
un número de transacciones a ejecutar. Horizontal / Vertical
Horizontal
Parte de una relación entre tuplas (condición)
Vertical
De una relación R produce fragmentos R1, R2, .. Rn <<llave primaria>>
Replicación
Incrementa la disponibilidad de la información
Strict Replica Control Protocol
son los que obligan tener una copia equivalente en cada nodo.
El protocolo ROWA (Read One Write All)
es el que convierte una lectura lógica a una lectura en cualquiera de sus replicas y
convierte una escritura lógica a una escritura en todas sus replicas. Esto se realiza
cuando la transacción de update realiza el commit, todas las replicas tienen el mismo
valor.
Lazy Replica Control Protocol
realizan la actualización de una o mas copias y después propagan los cambios en
todas las copias
Control de concurrencia
Varios usuarios conectados al mismo tiempo; pueden hacer mas de una transacción
al mismo tiempo.
Mecanismo
Ser tolerante a fallas / permite paralelismo para satisfacer requerimientos de
desempeño.
Transacciones rapidas poco tiempo
Tipos de concurrencia
Distribuida / serializable
Datos multidimensionales
Datos que pueden moldearse como atributos de dimensión y medida
DataMart
esta construido para soportar los requerimientos analíticos de un grupo en particular
de usuarios y proporcionando este soporte,
el data mart solo almacena un subconjunto de información corporativa.
Razones para crear
Para proporcionar acceso a los usuarios a la información que necesitan analizar mas
frecuentemente.
Para proporcionar información de forma que iguale la vista colectiva de la información por
un grupo de usuarios en el departamento, o grupo de usuarios interesados en un proceso de
negocio en particular.
Modelo de dimensionalidad
Técnica de diseño lógico que tiene como objetivo presentar la información de
manera estándar, intuitiva que proporciona el acceso de alto desempeño
Tipos : estrella, starflake schema, copo de nieve
Beneficios de DWH
Alto retorno de inversión potencial.
Ventaja competitiva.
Incrementa la productividad de los tomadores de decisiones.
Metadata
Descripción de los datos, nos dice de donde viene la información
Asegura la integración exitosa del DWH
Tecnologías para DWH/Herramientas
Extracción
Transformación
Carga (ETL)
Procesos
EDW (Datawarehouse empresarial)

DWH
Lo usan para que las empresas tomen decisiones y tengan ventajas competitivas
ODS (Operational Data Soel)
Repositorio de información operacional actual integrada, utilizada para el análisis
Pivoteo
Muchas de estas operaciones tratan con agregación (aggregation). Agregación de una
medida a lo largo de un subconjunto de las dimensiones es hecho por pivoteo
(reorientación) de la vista multidimensional de la información.
roll-up y drill-down. Roll-up incrementa el nivel de agregación por medio de mover la jerarquía de
la dimensión. Por ejemplo, podemos hacer una operación de roll-up a lo largo de la dimensión del
tiempo para agregar ventas por año. Una operación drill-down es la inversa de la roll-up y es útil
para incrementar el nivel de detalle. Otra operación popular es slice and dice la cual corresponde a
seleccionar un proyecto en un subconjunto de dimensiones. Otras operaciones tratan con atributos
de rango y calculo.b |
Segundo parcial
1. ¿Qué es el modelo orientado a objetos?
OOMD un modelo de datos (lógico) que captura la semántica de los objetos
soportada en programación orientada a objetos.
2. Menciona dos tipos de persistencias en OODBMS

• Persistencia por clases. El enfoque mas sencillo, pero menos
conveniente, consiste en declarar que una clase es persistente. Todos
los objetos de la clase son, por lo tanto, persistentes de manera
predeterminada. Todos los objetos de la clase no persistentes son
transitorios
• Persistencia por creación. En este enfoque se introduce una sintaxis
nueva para crear los objetos persistentes mediante la extensión de la
sintaxis para la creación de los objetos transitorios. Por lo tanto, los
objetos son persistentes o transitorios en función de la forma de crearlos.
Varios OODBMS siguen este enfoque.
• Persistencia por marcas. Una variante del enfoque anterior es marcar
los objetos como persistentes después de haberlos creado. Todos los
objetos se crean como transitorios pero, si un objeto tiene que persistir
mas allá de la ejecución del programa, hay que marcarlo como
persistente de manera explicita antes de que este concluya. Este
enfoque, a diferencia del anterior, pospone la decisión sobre la
persistencia o transitoriedad hasta después de la creación del objeto.
• Persistencia por alcance. Uno o varios objetos se declaran objetos
persistentes (objetos raíz) de manera explicita. Todos los demás objetos
serán persistentes si y solo si se pueden alcanzar desde algún objeto
raíz mediante una secuencia de una o varias referencias.
3. ¿Qué son los tipos de datos complejos?

Son aquellos datos que están representados como un conjunto de campos que
proporcionan un modelo fácil de aprender.
4. Crear un tipo de datos cliente con las columnas id, nombre, dirección y fecha de
nacimiento:
CREATE TYPE Cliente AS(id VARCHAR(8), nombre VARCHAR(32),
dirección VARCHAR(64), fechaNacimiento DATE)
NOT FINAL
Después crear una tabla de clientes con este tipo de dato más la columna
fechaIngreso:
CREATE TABLE clientes (x Cliente, fechaIngreso DATE)
Hacer el ejemplo de la inserción de un registro a esta tabla de clintes:

INSERT INTO clientes (NEW Cliente(‘123’,’José Reyes’, ‘Conocido’, ’14-12-1989’),
DATE ’12-14-89)
5. ¿Qué son los datos semi-estructurados en xml?
Son datos que pueden ser irregulares o incompletos y tienen una estructura que
puede cambiar rápidamente o impredeciblemente.
6. ¿Qué elementos puede encontrar en los documentos xml?
7. Mencione al menos dos tecnologías relacionadas con xml

DOM, SAX, XSL, XSLT, XPath, XPointer, Xlink, Xhtml, SOAP, WSDL
8. Realice un query con xQuery o Flwor expression que haga los siguiente
9. ¿Qué es datawarehouse y que tipo de procesamiento se utiliza?

Una colección orientada a sujetos de datos integrados desde varias DB
operacionales.
Utiliza un procesamiento OLTP
10. ¿Qué es un datamart?

Una base de datos que contiene un subconjunto de información corporativa para
soportar los requerimientos analíticos de unidades de negocios en particular o para
soportar usuarios que comparten información de los mismos requerimientos para
analizar in proceso de negocio particular.
11. Describa una metodología de las dos que se revisaron en clase que hay para
datawarehouse
En la metodología de Kimball el datamart es la implementación física de un esquema
simple (modelo dimensional) modelado en un proceso de negocio en particular (por
ejemplo la venta de propiedades). Los usuarios en el data mart de Kimball se
pueden distribuir a través de la empresa pero compartir los mismos requerimientos
para analizar un proceso de negocio particular. Cuando todos los procesos de
negocio de una empresa están representados como data marts, la integración de
data marts forman el EDW.
Con la metodología de Inmon un data mart es la implementación física de la base de

datos que soporta los requerimientos analíticos de una unidad de negocio en
particular (tal como el departamento de ventas) en la organización. El data mart de
Inmon recibe información del EDW.
1. Describa uno de los modelos de dimensionalidad
2. Realice el query y la salida del mismo de la siguiente tabla utilizando ROLLUP

BASES DE DATOS
AVANZADAS
TEMA
BASES DE DATOS XML
AGENDA
Introducción
Elementos XML, Atributos XML
Documentos XML
Datos semi-estructurados
Definiciones de tipo de documento (DTD)
Lenguajes de Consulta para XML
Introducción
A diferencia de otros el lenguaje Extensible Markup

Language (XML) no se creó como una tecnología para
bases de datos. En realidad, al igual que el lenguaje Hyper-
text Markup Language (HTML) en el que esta basado
World Wide Web. XML tiene sus raíces en la gestión de
documentos y esta derivado de un lenguaje para estructurar
grandes documentos conocido como Standard
Generalized Markup Language (SGML). Sin embargo,
a diferencia de SGML y de HTML, XML puede representar
datos de bases de datos, así como muchas clases de datos
estructurados. Es particularmente útil como formato de
datos cuando las aplicaciones se deben comunicar con otra
aplicación o integrar información de varias aplicaciones.
Introducción
Para comprender XML es importante entender sus raíces

como un lenguaje de marcas de documentos. El termino
marca se refiere a cualquier elemento en un documento del
que no se tiene intención que sea parte de la salida impresa.
Por ejemplo, un escritor que crea un texto que finalmente se
compone en una revista puede desear realizar notas sobre
como se ha de realizar la composición. Seria importante
introducir estas notas de tal forma que se pudieran distinguir
del contenido real; una nota como “usar un tipo mayor y
colocarlo en negritas” o “no olvidar este párrafo” no acabaría
impresa en la revista. estas notas comunican información
adicional sobre el texto. En un procesamiento electrónico de
documentos un lenguaje de marcas es una descripción
formal de la parte del documento que es contenido, la parte
que se marca y lo que significa la marca.
Introducción
Para la familia de lenguajes de marcado, en los que

incluyen HTML, SGML y XML, las marcas adoptan la
forma de etiquetas encerradas entre corchetes angulares
<>. Las etiquetas se usan en pares, con <etiqueta> y
</etiqueta> delimitando el comienzo y final de la
porción de documento a la cual se refiere la etiqueta. Por
ejemplo el titulo de un documento podría estar marcado
de la siguiente forma:
<title> Bases de Datos Avanzadas </title>

introducción
A diferencia de HTML, XML no impone las etiquetas

permitidas y se pueden elegir como sea necesario para cada
aplicación. Esta característica es la clave de la función
principal de XML en la representación e intercambio de
documentos, mientras que HTML se usa principalmente para
el formato de documentos.
Comparado con el almacenamiento en una base de datos
relacional, la representación XML puede parecer poco
eficiente, puesto que los nombres de las etiquetas se repiten
por todo el documento. Sin embargo, a pesar de esta
desventaja, una representación XML presenta ventajas
significativas cuando se usa para el intercambio de datos
entre empresas y para almacenar información estructurada
en archivos.
Introducción
En primer lugar la presencia de las etiquetas hace que el

mensaje sea autodocumentado, es decir, no se tiene que
consultar un esquema para comprender el significado del texto.
Por ejemplo, el fragmento anterior puede leer al siguiente
fácilmente.
En segundo lugar, el formato del documento no es rígido. Por
ejemplo, si algún remitente agrega información adicional tal
como una etiqueta ultimo_acceso que informa de la ultima
fecha de la que se ha accedido a la cuenta, el recipiente de los
datos XML puede sencillamente ignorar la etiqueta. La
capacidad de reconocer o ignorar las etiquetas inesperadas
permite al formato de los datos evolucionar con el tiempo sin
invalidar las aplicaciones existentes. De forma similar, la
posibilidad de que la misma etiqueta aparezca varias veces hace
que sea fácil representar atributos multivalorados.
Introducción
En tercer lugar, XML permite estructuras anidadas. El pedido de compra

mostrado en la siguiente figura ilustra las ventajas de tener estas estructuras.
Cada pedido de compra tiene un comprador y una lista de elementos como
dos de sus estructuras anidadas. Cada elemento tiene a su vez un
identificador, una descripción y un precio anidados, mientras que el
comprador tiene un nombre y dirección anidados.
Esta información se podria haber dividido en varias relaciones en el modelo
relacional. La información de los elementos se habria almacenado en una
relación, la información del comprador en una segunda relación, los pedidos
de compra en una tercera y la relación entre los pedidos de compra,
compradores y elementos en una cuenta.
La representación relacional ayuda a evitar la redundancia; por ejemplo, las
descripciones de los elementos se almacenarían solo una vez por cada
identificador de elemento en un esquema relacional normalizado. Sin
embargo, en el pedido de compra de XML, las descripciones se pueden repetir
en varios pedidos con el mismo elemento. No obstante, es atractivo recoger
toda la información relacionada con un pedido en una unica estructura
anidada, incluso añadiendo redundancia, cuando la información se tiene que
intercambiar con terceros.
Introducción
Finalmente, puesto que el formato XML esta

ampliamente aceptado hay una gran variedad de
herramientas disponibles para ayudar a su
procesamiento, incluyendo API’s para lenguajes de
programación para crear y leer datos XML, software de
exploración y herramientas de bases de datos.
En la siguiente figura se muestra la representación de
XML de un pedido de compra
Figura. Representación XML de un pedido de compra
<pedido_compra>
<identificador> P-101 </identificador>
<comprador>
<nombre> Coyote Willie </nombre>
<dirección> Mesa Flat, Route 66, Arizona 12345, EEUU </dirección>
</comprador>
<proveedor>
<nombre> Proveedores ACME, S.A. </nombre>
<direccion> 1. Broadway, Nueva York, NY, EEUU </direccion>
</proveedor>
<lista_elementos>
<elemento>
<identificador> EA1 </identificador>
<descripcion> Trineo propulsado por cohetes atómicos </descripcion>
<cantidad> 2 </cantidad>
<precio> 199.95 </precio>
</elemento>
<elemento>
<identificador> PF2 </identificador>
<descripcion> Pegamento</descripcion>
<cantidad> 1 </cantidad>
<unidad_medida> litro </unidad_medida>
<precio> 29.95 </precio>
</elemento>
</lista_elementos>
<costo_total> 429.85 </costo_total>
<forma_de_pago> Reembolso </forma_de_pago>
<forma_envio> Avion </forma_envio>
</pedido_compra>
Estructura de datos XML
El constructor fundamental de un documento XML es el elemento. Un

elemento es un par de etiquetas de inicio y fin coincidentes y todo el
texto que aparece entre ellas. Los documentos XML deben tener un
único elemento raíz que abarque al resto de los elementos en el
documento. En el ejemplo anterior, el elemento <pedido_compra>
forma el elemento raíz. Además los elementos en un documento XML se
deben anidar adecuadamente.
Aunque el anidamiento adecuado es una propiedad intuitiva es necesario
definirla formalmente. Se dice que el texto aparece en el contexto de un
elemento si aparece entre la etiqueta de inicio y la etiqueta de
finalización de dicho elemento. Las etiquetas están anidadas
adecuadamente si toda la etiqueta de inicio tiene una única etiqueta de
finalización coincidente que esta en el contexto del mismo elemento
padre.
Las representaciones anidadas se usan ampliamente en las aplicaciones
de intercambio de datos XML para evitar las reuniones.
Por ejemplo, un pedido de compra almacenaría la dirección

completa del emisor y el receptor de una forma redundante en
varios pedidos de compra, mientras que en una representación
normalizada puede requerir una reunión de registros de pedidos de
compras con una relación dirección_empresa para obtener la
información de la dirección.
Además de los elementos, XML especifica la noción de atributo.
Por ejemplo, el tipo de una cuenta se puede representar como un
atributo.
...
<cuenta tipo_cuenta=“corriente”>
<numero_cuenta> C-102 </numero_cuenta>
<nombre_sucursal> Centro </nombre_sucursal>
</cuenta>
...
Los atributos de un elemento aparecen como pares nombre=valor

antes del cierre “>”. de una etiqueta. Los atributos son cadenas y
no contienen marcas. Además los atributos pueden aparecer
solamente una vez en una etiqueta dada, al contrario de los
subelementos que queden estar repetidos.
Es importante la distinción entre subelemento y atributo (un
atributo es texto implícito que no aparece en el documento
impreso o visualizado). Sin embargo, en las aplicaciones de bases
de datos y de intercambio de datos XML, esta distinción es menos
relevante y la elección de representar los datos como un atributo o
un subelemento es frecuentemente arbitraria.
Puesto que los documentos XML se diseñan para su intercambio
entre aplicaciones se tiene que definir un mecanismo de espacio
entre nombres (namespaces) para permitir a las
organizaciones especificar nombres únicos globales para que se
utilicen como marcas en los documentos.
Un documento puede tener mas de un espacio de nombres,

declarado como parte del elemento raíz. Se pueden entonces
asociar elementos diferentes con espacios de nombres distintos.
Se puede definir un espacio de nombres predeterminado mediante
el uso del atributo xmins en lugar del xmins:XP en el elemento
raíz. Los elementos sin un prefijo de espacio de nombres explicito
pertenecen entonces al espacio de nombres predeterminado.
<banco xmins:BP=“http://www.bancoprincipal.com”>
...
<BP:sucursal>
<BP:nombre_sucursal> Centro </BP:nombre_sucursal>
<BP:ciudad_sucursal> Capital >/BP:ciudad_sucursal>
...
</banco>
Algunas veces es necesario almacenar valores que contienen etiquetas
XML. Para ello XML permite esta construcción:
<![CDATA[<cuenta> .... </cuenta>]]>
XML. Es un metalenguaje (un lenguaje para describir otros lenguajes)

que habilita a los diseñadores a crear sus propias etiquetas
personalizadas para proporcionar funcionalidad que no esta disponible
con HTML.
XML es una versión limitada de SGML. diseñado especialmente para
documentos Web.
SGML es un sistema para definir tipos de documentos estructurados y
lenguajes de marcas para representar instancias de otros tipos de
documentos (ISO, 1996). SGML ha sido el estándar para mantener
repositorios de documentos estructurados por mas de una década.
SGML permite a los documentos ser separados lógicamente en dos
partes:
Una parte que define la estructura del documento y la otra el
contenido del texto por si mismo. La definición de la estructura es
llamada Document Type Definition (DTD), dando a los
documentos una estructura separada definida y dando a los
autores la habilidad de definir estructuras personalizadas. SGML
proporciona un sistema de gestión de información
extremadamente poderoso. Sin embargo, SGML no ha tenido tan
amplia aceptación, por su complejidad implícita.
XML intenta proporcionar funciones similares a SGML, pero
menos complejo y al mismo tiempo consistente con la red.
Significativamente XML retiene las ventajas de SGML de
extensibilidad, estructura y validación. Puesto que XML es una
forma limitada de SGML. Cualquier sistema SGML completo será
capaz de leer documentos XML (aun cuando lo opuesto no es
necesariamente cierto). Sin embargo, XML no esta intentando
reemplazar a SGML. De forma similar XML no esta intentando
reemplazar HTML, el cual también esta basado en SGML.
Al contrario, XML esta diseñado para complementar

HTML proporcionando varios tipos de información para
intercambiar a través de la red. De hecho el uso de XML
no esta limitado a marcas de texto, pero extensiblemente
significa que XML podría también ser aplicado a marcas
de sonido o imágenes. Tres lenguajes creados con XML
son MathML (Mathematics Markup Language), SMIL
(Synchronized Multimedia Integration Language) y CML
(Chemistry Markup Language) entre otros. XML esta
afectando muchos aspectos del área de Tecnología de
Información incluyendo interfaces graficas, sistemas
incrustados, sistemas distribuidos y gestión de bases de
datos.
Ventajas de XML
Simplicidad
Open estándar y de plataforma independiente.
Extensible
Reutilizable
Separación de contenido y presentación
Mejora el balanceo de cargas
Soporte para la integración de información de múltiples
fuentes
Habilidad para describir información desde gran variedad
de aplicaciones
Avanzados motores de búsqueda
Nuevas oportunidades
Resumen de características XML
Característica Ejemplo
XML declaration <?xml version=“1.1” encoding=“UTF-8”

standalone=“no”?>
Elementos o tags <staff> </staff>

Atributos <staff branchNo=“B0005”>
Entity reference <
Comments 
Sección CDATA y <?name pidata?>

procesamiento de instrucciones
Datos Semi-estructurados
Datos Semi-estructurados
Son datos que pueden ser irregulares o incompletos y tienen
una estructura que puede cambiar rápidamente o
impredeciblemente.
Los datos semi-estructurados son datos que tienen una
estructura, pero la estructura puede no ser rígida, regular o
completa y generalmente los datos no conforman un
esquema fijo (algunos términos para definir estos datos son
schema-less o self-describing). En los datos semi-
estructurados, la información que es normalmente asociada
con un esquema esta contenida en los datos en si. En algunas
formas de datos semi-estructurados, no hay un esquema
separado; en otros, este existe pero coloca solo limitaciones
sueltas en la información.
En contraste RDBMS requieren un esquema orientado de

tablas predefinidas y toda la información administrada por el
sistema debe adherirse a esta estructura. Aunque OODBMS
permiten una estructura mas rica que RDBMS también
requieren que todos los datos se adhieran a los esquemas
predefinidos orientados a objetos. Sin embargo, con un
DBMS basado en datos semi-estructurados. El esquema es
“descubierto” desde la información, en lugar de ser impuesto
desde el principio.
Datos semi-estructurados han ganado importancia
recientemente por varias razones, las cuales las siguientes son
de particular interes.
Es deseable tratar orígenes de Web como una base de datos, pero

no se pueden limitar estos orígenes a un esquema;
Es deseable tener un formato flexible para el intercambio de
información entre bases de datos diferentes;
La aparición de XML como un estándar para la representación e
intercambio de información en la Web y la similitud entre
documentos XML y datos semi-estructurados.
Muchos de estos enfoques de gestión de datos semi-estructurados
están basados en lenguajes de consulta, que atraviesan
representaciones de arboles con etiquetas. Sin un esquema, la
información puede identificarse solo especificando su posición
dentro de la colección en lugar de sus propiedades estructurales.
Esto significa que las consultas pierden su naturaleza tradicional
declarativa y se convierten mas navegacionales.
Document Type Definitions (DTD)
DTD define la sintaxis valida de un documento XML listando

los nombres de los elementos que pueden ocurrir en el
documento, tales elementos pueden aparecer en
combinación con cualquiera de los otros, como los elementos
pueden ser anidados, los atributos están disponibles para
cada tipo de elemento y así sucesivamente. El termino
vocabulario es algunas veces utilizado para referirse los
elementos utilizados en una aplicación en particular. La
gramática es especificada utilizando EBNF (Extended
Backus-Naur Form) , no sintaxis XML. Aunque el DTD es
opcional se recomienda para conformidad del documento.
Hay cuatro tipos de declaraciones DTD: declaraciones del
tipo elemento, declaraciones de listas de atributos,
declaraciones de entidades y declaraciones de notaciones
Declaraciones del tipo elemento
Identifican las reglas para los elementos que pueden ocurrir en el
documento XML. Por ejemplo en la siguiente figura, se tiene especificada
la siguiente regla (o modelo contenido) para el elemento STAFFLIST:
<!ELEMENT STAFFLIST (STAFF)*>
Es estado de los elementos STAFFLIST consiste en cero o mas elementos
STAFF
Las opciones para la representación son:
- asterisco(*), el cual indica cero o mas ocurrencias para el elemento.
- mas (+) el cual indica una o mas ocurrencias para un elemento.
- signo de interrogación (?), el cual indica cualquiera de las siguientes
dos opciones cero ocurrencias o exactamente una ocurrencia para un
elemento.
Un nombre con puntuación no calificada ocurre exactamente una vez.
Las comas entre los nombres de los elementos indica que deben ocurrir
en ese orden. Si se omiten las comas, los elementos pueden aparecer en
cualquier orden
Ejemplo 1 de XML
<?xml version=“1.1” encoding=“UTF-8” standalone=“no”?>
<?xml:stylesheet type = “text/xsl” href = “staff_list_xsl”?>
<!DOCTYPE STAFFLIST SYSTEM “staff_list_dtd”>
<STAFFLIST>
<STAFF branchno = “B005”>
<STAFFNO>SL21</STAFFNO>
<NAME>
<FNAME>John</FNAME><LNAME>White</LNAME>
</NAME>
<POSITION>Manager</POSITION>
<DOB>1945-10-01</DOB>
<SALARY>30000</SALARY>
</STAFF>

<STAFFNO>SG37</STAFFNO>
<NAME>
<FNAME>Ann</FNAME><LNAME>Beech</LNAME>
</NAME>
<POSITION>Assitant</POSITION>
</STAFF>
</STAFFLIST>
Figura Document Type Definition para el documento de la
pagina anterior
<!ELEMENT STAFFLIST (STAFF)*>

<!ELEMENT STAFF (NAME, POSITION,DOB?,SALARY)*>
<!ELEMENT NAME (FNAME,LNAME)>
<!ELEMENT FNAME (#PCDATA)>
<!ELEMENT LNAME (#PCDATA)>
<!ELEMENT POSITION (#PCDATA)>
<!ELEMENT DOB (#PCDATA)>
<!ELEMENT SALARY (#PCDATA)>
<!ATTLIST STAFF branchNo CDATA #IMPLIED>
Declaraciones de listas de atributos

Identifican cuales elementos pueden tener atributos, que
atributos deben tener valores, que valores deberán contener
los atributos y cuales son los valores opcionales. Cada
declaración de atributo tiene tres partes: un nombre, un tipo
y un valor por default opcional. Hay seis tipos de atributos
posibles:
CDATA- character data, contiene cualquier texto. La cadena
de caracteres no será procesada por el procesador XML y
simplemente pasará directamente a la aplicación.
ID- utilizado para identificar elementos individuales en un
documento. Los IDs deberán corresponder a un nombre de
elemento y todos los valores de los IDs en el documento
deberán ser diferentes.
IDREF o IDREFS- deberá corresponder a un valor o a un solo
atributo ID para el mismo elemento en el documento. Un atributo
IDREFS puede contener múltiples valores IDREF separados por
espacios.
ENTITY o ENTITIES- deberá corresponder a el nombre de una
sola entidad. Una vez mas el atributo ENTITIES puede contener
múltiples valores ENTITY separados por espacios.
NMTOKEN o NMTOKENS- una forma limitada de una cadena
de caracteres, generalmente consistente de una sola palabra. El
atributo NMTOKENS puede contener múltiples valores de
NMTOKEN separados por espacios en blanco.
Lista de nombres- los valores que el atributo puede tener (que
es un tipo enumerado).
Por ejemplo, la siguiente declaración de atributo es utilizada para
definir un atributo llamado branchNo para el elemento STAFF:
<!ATTLIST STAFF branchNo CDATA #IMPLIED>
Esta declaración establece que el valor branchNo es una cadena CDATA y es
opcional (#IMPLIED) sin valor por defecto proporcionado. A parte de
#IMPLIED también puede especificarse #REQUIRED para indicar que el
atributo debe proporcionarse siempre. Si ninguno de estos dos se proporciona,
entonces el valor contiene el valor por default. La palabra reservada #FIXED
puede utilizarse para indicar que el atributo debe siempre tener el valor por
defecto. En un segundo ejemplo, podríamos definir el elemento genero (SEX)
para tener un atributo gender conteniendo el valor M (por default) o F como
sigue:
<!ATTLIST SEX gender (M | F) “M”>
Declaraciones de entidades y notaciones

Las declaraciones de entidades asocian un nombre con algunos fragmentos de
contenido, tales como piezas de texto regular, una pieza de DTD, o una referencia
a un archivo externo conteniendo texto o datos binarios. Las declaraciones de
notaciones identifican datos binarios externos, los cuales simplemente son
pasados por el procesador XML a la aplicación.
Por ejemplo: se necesita declarar una entidad para el texto DreamHome
Estate Agents como sigue:
<!ENTITY DH “DreamHome Estate Agents”>
La presencia de entidades externas sin procesar es la responsabilidad de la

aplicación. Alguna información sobre el formato interno de la entidad debe declararse
después de identificar que indica la localidad de la entidad; por ejemplo:
<!ENTITY dreamHomeLogo SYSTEM “dreamhome.jpg” NDATA JPEGFormat>

<!NOTATION JPEGFormat SYSTEM http://www.jpeg.org>
La presencia del token NDATA indica que la entidad no es procesada; el nombre

arbitrario seguido por el token es simplemente una llave para la declaración de
notación subsecuente. La declaración de la notación iguala este nombre con un
identificador que la aplicación utiliza para conocer como manejar esta entidad.
Element identity, IDs and ID Reference

XML reserva el atributo tipo ID que proporciona una llave única para ser
asociada con un elemento. En resumen, el atributo del tipo IDREF permite
un elemento como referencia a otro elemento con la llave designada y un
atributo del tipo IDREFS permite un elemento que haga referencia a
múltiples elementos. Por ejemplo, en un modelo mas relajado la relación
Branch Has Staff, podrá definir los siguientes dos atributos para los
elementos STAFF and BRANCH
<!ATTLIST STAFF staffNo ID #REQUIRED>

<!ATTLIST BRANCH staff IDREFS #IMPLIED>
Entonces se podrán utilizar estos atributos como se muestra en la siguiente

figura
Figura A Ejemplo de la utilización de ID e IDREFS
<STAFF staffNo = “SL21”>

<NAME>
</NAME>
</STAFF>
<STAFF staffNo = “SL41”>
<NAME>
<FNAME>Julie</FNAME><LNAME>Lee</LNAME>
</NAME>
</STAFF>
<BRANCH staff = “SL21 SL41”>
<BRANCHNO>B005</BRANCHNO>
</BRANCH>
Validación de documento
Las especificaciones XML proporcionan dos niveles de procesamiento en los
documentos: well-formed y valid. Un procesador no validado asegura que un
documento XML sea well-formed antes de pasar a la información en el
documento en la aplicación. Un documento XML que conforman las reglas
estructurales y notacionales del XML están consideradas well-formed. Entre
otros, documentos well-formed deben conformar las siguientes reglas:
El documento debe iniciar con la declaración XML; por ejemplo, <?xml
version “1.1”?>;
Todos los elementos deberán estar contenidos dentro de un elemento raíz;
Los elementos deberán anidarse en la estructura de árbol sin ningún traslape;
Todos los elementos que no estén vacíos deben tener una etiqueta de inicio y
final.
El procesador de validación no solo revisará que el documento XML sea well-

formed, también que sea conforme con el DTD, en tal caso el documento XML
es considerado valid.
En esta parte se discutirán algunas tecnologías relacionadas con XML
que son importantes para comprender el desarrollo de aplicaciones
XML.
Interfaces DOM y SAX
Las aplicaciones XML generalmente caen en dos categorías: basadas en
árbol o en eventos. DOM (Document Object Model) es una
aplicación basada en árbol para XML que proporciona un punto de vista
de objetos a la información. La aplicación fue creada por el W3C y
describe un conjunto de interfaces (plataformas lenguajes) neutrales
que pueden representar cualquier documento XML y HTML well-
formed. DOM construye una representación en memoria del
documento XML y proporciona clases y métodos para permitir a la
aplicación navegar y procesar el árbol. DOM define una interface Nodo,
con subclases Element attribute y Character-Data. La interface Nodo
tiene metodos para accesar los componentes del nodo tales como
parentNode(), el cual regresa al nodo padre y childrenNode(), el cual
regresa un conjunto de nodos hijos. En general la interface DOM es mas
útil para realizar manipulaciones estructurales del árbol XML, tales
como agregar, borrar y reordenar elementos.

La representación del documento XML revisada en el ejemplo 1
es una estructura de árbol que se muestra en la siguiente figura.
STAFFL
IST
STAFF STAFF
STAFFN POSITI
NAME DOB SALARY
O ON
SL21 Manager 1945-10-01 30000
FNAME LNAME
John White
Figura B representación de un documento XML de la figura A
SAX (Simple API for XML) es una aplicación basada

en eventos de acceso en serie para XML que utiliza
callbacks para reportar eventos analizados para la
aplicación. Por ejemplo, hay eventos para inicio y fin de
elementos. La aplicación maneja estos eventos a través
de administradores de eventos personalizados. A
diferencia de las aplicaciones basadas en arboles, estas
aplicaciones no construyen una representación de árbol
construida en memoria del documento XML. Esta
aplicación fue un producto de colaboración con XML-
DEV mailing list (XML.org), en lugar de un producto de
W3C.
XSL y XSLT
En HTML el estilo por defecto esta construido dentro de los
browsers puesto que el conjunto de etiquetas para HTML
esta predefinido y fijo. Cascading Stylesheet
Specification (CSS) permite al desarrollador proveer una
representación alternativa para las etiquetas. CSS puede
también ser utilizado para representar un documento XML
en un browser pero no tiene la habilidad de hacer
alteraciones estructurales en el documento. XSL
(eXtensible Stylesheet Language es una recomendación
formal de W3C que ha sido creada específicamente para
definir como los datos de un documento XML son entregados
y para definir como un documento XML puede
transformarse en otro documento (W3C, 2001 a). Es similar
a CSS, aunque mas poderoso.
XSLT (XSL Transformations) forma un subconjunto de XSL
(W3C, 2007a). Es un lenguaje en sentido de marcas y
programación, proporciona un mecanismo para transformar la
estructura XML en otra estructura XML, HTML o cualquier otro
formato basados en texto (tal como SQL). Aunque puede ser
utilizado para crear la salida de una pagina web, la principal
característica de XSLT es la de cambiar las estructuras en lugar de
solo cambiar la representación de estas. como en el caso de CSS.
XSLT es importante pues proporciona un mecanismo para
cambiar en forma dinámica la vista del documento y para filtrar
información. Es también lo suficientemente robusto para codificar
reglas de negocio y puede generar graficas (no solo documentos)
de la información. También puede tener comunicación entre
servidores – especialmente en conjunción con módulos scripting
que se pueden integrar dentro de XSLT- y también puede generar
los mensajes apropiados dentro del cuerpo de XSLT por si mismo.
Outline XSL stylesheet para el documento del ejemplo 1
<?xml version = “1.1”?>

<xsl:stylesheet xmlns:xsl = http://www.w3c.org/TR/WD-xsl>
<xsl:template match = “/”>
<html>
<body background = “sky.jpg”>
<center><h2><i>DreamHome</i> Estate Agents </h2></center>
<table border = “1” bgcolor = “#ffffff”>
<tr>
<th bgcolor= “#c0c0c0” bordercolor=“#000000”>staffNo</th>
<!– repeat for other columns headings -->
</tr>
<xsl:for-each select=“STAFFLIST/STAFF”>
<tr>
<td bordercolor=“#c0c0c0”><xsl:value-of select=“STAFFNO”/></td>
<td bordercolor=“#c0c0c0”><xsl:value-of select=“NAME/FNAME”/></td>
<!– repeat for other elements -->
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
XPath (XML Path Language)
XPath es un lenguaje declarativo de consultas que proporciona una
sintaxis simple por medio del direccionamiento de partes de un
documento XML (W3C, 1999c, 2007b). Fue diseñado para utilizarse con
XSLT (para identificación de patrones) y XPointer (para
direccionamiento). Con XPath las colecciones de elementos pueden ser
recuperadas especificando un directorio, como si fuera una ruta, con
cero o mas condiciones colocadas en la ruta. XPath utiliza un sintaxis
compacta basada en cadenas de caracteres en lugar de una sintaxis
basada en estructuras XML, permitiendo a XPath expresiones que no se
pueden utilizar en XML y URIs (Uniform Resource Identifier) es
una cadena de caracteres corta que identifica inequívocamente un
recurso (servicio, página, documento, dirección de correo electrónico,
enciclopedia, etc.). Normalmente estos recursos son accesibles en una
red o sistema. Los URI pueden ser localizadores uniformes de
recursos (URL), Uniform Resource Name (URN), o ambos.
Un URI consta de las siguientes partes:
Esquema: nombre que se refiere a una especificación para asignar los identificadores,
e.g. urn:, tag:, cid:. En algunos casos también identifica el protocolo de acceso al recurso, por
ejemplo http:, mailto:, ftp:.
Autoridad: elemento jerárquico que identifica la autoridad de nombres (por
ejemplo //www.example.com).
Ruta: Información usualmente organizada en forma jerárquica, que identifica al recurso en
el ámbito del esquema URI y la autoridad de nombres (e.g. /domains/example).
Consulta: Información con estructura no jerárquica (usualmente pares "clave=valor") que
identifica al recurso en el ámbito del esquema URI y la autoridad de nombres. El comienzo
de este componente se indica mediante el carácter '?'.
Fragmento: Permite identificar una parte del recurso principal, o vista de una
representación del mismo. El comienzo de este componente se indica mediante el carácter
'#'.
Aunque se acostumbra llamar URL a todas las direcciones web, URI es un identificador más
completo y por eso es recomendado su uso en lugar de la expresión URL.
Un URI se diferencia de un URL en que permite incluir en la dirección una subdirección,
determinada por el “fragmento”.
XPath trata a un documento XML como un árbol lógico (ordenado) con
nodos para cada elemento, atributo, texto, instrucción de procesamiento,
comentario, namespace y raíz. La base del mecanismo de
direccionamiento es el context node (un apuntador inicial) y el
location path, el cual describe una ruta desde un punto de el
documento a otra, proporcionando la forma de que los elementos en el
documento XML sean direccionados.
XPointer también puede ser utilizado para especificar una localización
absoluta o relativa. Una ruta de localización esta compuesta de series de
pasos (steps) unidos con “/”, los cuales tienen la función como “/” en
una ruta de directorio. Cada “/” se mueve hacia abajo en el árbol de un
paso anterior.
Cada paso consiste de predicados bases y opcionales. en el que el base
consiste de un eje, el cual especifica la dirección en la que se va a navegar
y el node test. Un node test identifica un tipo de nodo en el documento
(usualmente el nombre de un elemento, pero también puede ser una
función tal como text() para nodos de texto o simplemente node() para
cualquier otro tipo de node).
XPath define 13 tipos de ejes, incluyendo parent,

ancestor (hacia arriba), child, descendant (hacia abajo),
preceding, preceding-sibling (a la izquierda), following,
following-sibling (a la derecha). Por ejemplo en la figura
B, el elemento STAFF tiene un eje hijo que consiste de
cinco nodos (STAFFNO, NAME, POSITION, DOB y
SALARY). Un predicado ocurre en paréntesis cuadrados
después de la base. Cuando un elemento contiene mas
de un subelemento, un subelemento puede seleccionarse
usando [position()=positionNumber], con
positionNumber iniciando en 1. Xpath proporciona una
sintaxis abreviada y no abreviada. Algunos ejemplos los
mostramos en la siguiente tabla.
Tabla 1 Ejemplos de rutas de localización
rutas de localización Significado
. Selecciona el nodo de contexto
.. Selecciona el padre del nodo de contexto
/ Selecciona el nodo raíz, o un separador entre pasos de la ruta
// Selecciona los descendientes del nodo actual
/child:STAFF (o solo /STAFF) Selecciona todos los elementos STAFF que son hijos de raíz
child:STAFF (o solo STAFF) Selecciona el elemento STAFF hijo del nodo contexto
attribute:branchNo(o solo Selecciona el atributo branchNo del nodo contexto
@branchNo
attribute:* (o solo @*) Selecciona todos los atributos en el nodo contexto
child:STAFF[3] Selecciona el tercer elemento que es hijo del nodo contexto
/child:STAFF[@branchNo=“B00 Selecciona todos los elementos STAFF que tienen un atributo
5”] el cual branchNo es igual a B005
/child:STAFF[@branchNo=“B00 Selecciona el primer elemento STAFF que tienen un atributo el
5”] [position()=1] cual branchNo es igual a B005
XPointer (XML Pointer Language)
XPointer proporciona acceso a los valores de los atributos o del
contenido de los elementos en cualquier lugar dentro del documento
XML (W3C,2000d, 2003c). Un XPointer es básicamente una expresión
XPath que ocurre dentro de la URI. Entre otras cosas, con Xpointer
podemos ligar las secciones de texto, seleccionando elementos o
atributos particulares y navegar a través de ellos. También se puede
seleccionar información contenida dentro de un conjunto de nodos, lo
cual no se puede hacer con XPath.
En resumen, a la definición de nodos, Xpointer también define points y
ranges, los cuales combinados con los nodos crean locations. Un point
es la posición dentro del documento XML y un range representa toda la
estructura del XML y el contenido entre un punto inicial y el final, cada
uno de los cuales puede localizarse en medio del node. Por ejemplo, el
siguiente XPointer selecciona un rango iniciando al principio del
elemento hijo STAFF que tiene un atributo branchNo con valor B005 y
finaliza al final del elemento STAFF que tiene el atributo branchNoB003.
Xpointer (/child::STAFF[attribute::branchNo = “B005”] to
/child::STAFF[attribute::branchNo = “B003”])
En este caso se seleccionan ambos nodos de STAFF.
XLink (XML Linking Language)

Xlink permite insertar elementos dentro de documentos XML a razón de crear y
describir links entre recursos (W3C, 2001b). Este utiliza sintaxis XML para crear
estructuras que puedan describir links similares a hyperlinks simples
unidireccionales de HTML así como links mas sofisticados. hay dos tipos de
XLinks: simples y extendidos. Un link simple conecta un recurso fuente a un
destino; un link extendido conecta cualquier cantidad de recursos. En resumen,
es posible almacenar links en una base de datos separada llamada (linkbase)
esta proporciona una forma de localización independiente – aunque los links
cambien los documentos originales XML permanecen sin cambio y solo se tiene
que actualizar la base de datos.
XHTML
XHTML (eXtensible HTML) 1.0 es una reformulación de
HTML 4.01 en XML 1.0 y fue realizado para ser la nueva
generación de HTML (W3C, 2002a) básicamente es una
versión mas estricta y limpia de HTML. Por ejemplo:
tags y atributos deben ser en minúsculas;
Todos los elementos XHTML deben tener una tag al final;
Los valores de los atributos deberán estar entre comillas y
no se permite la minimización
El atributo ID reemplaza al atributo name
Los documentos deberán cumplir con las reglas XML
Simple Object Access Protocol (SOAP)

SOAP es un protocolo de mensajería basado en XML que
define un conjunto de reglas para estructurar mensajes
(W3C, 2007c) El protocolo puede ser utilizado para envío de
mensajes de una sola vía, pero es también útil para realizar
diálogos de respuesta RPC (Remote Procedure Call). SOAP
no esta atado a ningún sistema operativo, lenguaje de
programación o protocolo de transporte en particular,
aunque HTTP es popular. Esta independencia hace que
SOAP un bloque importante de construcción para desarrollo
de servicios Web. En resumen, una importante ventaja de
SOAP es que la mayoría de los firewalls permiten pasar a
HTTP, facilitando el intercambio de información punto a
punto de SOAP (aunque el administrador del sistema podría
bloquear selectivamente las solicitudes de SOAP).
Un mensaje de SOAP es un documento XML común conteniendo
los siguientes elementos:
Un elemento obligatorio Envelope que identifica el documento
XML como un mensaje SOAP.
Un elemento opcional Header que contiene información
especifica de la aplicación tal como autenticación o información
de pago. Este también tiene tres atributos que específicamente
podrán procesar el mensaje, aun si el procesamiento es opcional
u obligatorio y las reglas de codificación que describen los tipos
de datos para la aplicación.
Un elemento obligatorio Body Header que contiene
información de llamada y respuesta.
Un elemento opcional Fault que proporciona información
sobre los errores que ocurrieron mientras se procesa el mensaje.
La siguiente figura ilustra un mensaje SOAP que obtiene el precio
de una propiedad PG36.
Ejemplo de un mensaje SOAP
<?xml version = “1.1”?>

<soap:Envelope xmlns:soap=http://www.w3.org/2001/12/soap-envelope”
soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding”>
<soap:Body>
<m:GetPriceRequest xmlns:m=http://www.dreamhome.com.uk/prices>
<m:item>PG36</m:item>
</ m:GetPriceRequest>
</soap:Body>
</ soap:Envelope>
Web Services Description Language (WSDL)

WSDL es un protocolo basado en XML para definir un servicio
Web. Este especifica la ubicación del servicio, las operaciones que
el servicio expone, los mensajes (SOAP) involucrados y el
protocolo de comunicación utilizado para hablar con el servicio.
La notación que un archivo WSDL utiliza para describir el formato
del mensaje es típicamente basado en un esquema XML estándar
haciéndolo neutral de lenguaje y plataforma. Programadores o
mas generalmente, herramientas de desarrollo automatizadas
pueden crear archivos WSDL para describir un servicio y pueden
tener la descripción disponible en la Web. Los programadores por
parte del cliente y herramientas de desarrollo pueden utilizar
descripciones WSDL para publicarse y obtener información sobre
los servicios web y después construir y crear proxies o plantillas de
programas con acceso a estos servicios.
WDSL 2.0 describe un servicio web en dos partes: una parte abstract y
otra concrete (W3C, 2007). En el nivel abstract, WSDL, describe un
servicio web en términos de los mensajes que se envían y reciben; los
mensajes son descritos independientes al formato especifico utilizando
un tipo de sistema, típicamente un esquema XML:
Un patrón para el intercambio de mensajes identifica la secuencia y
cardinalidad de los mensajes enviados y/o recibidos así como
lógicamente son enviados/recibidos.
Un operation liga el patrón de intercambio del mensaje con uno o
mas mensajes.
Una interface agrupa operaciones juntas sin comprometer al
transporte o el formato de conexión.
En el nivel concrete, un binding especifica el transporte y el detalle del
formato de conexión para una o mas interfaces. Un endpoint asocia la
dirección de red con un binding y un servicio agrupa endpoints que
implementan una interface en común. La siguiente figura ilustra los
conceptos WDSL.
Conceptos WSDL
Mensajes
endpoints
uri uri uri
bindings
interface interface
operation operation
operation operation
service
Resource
Universal Discovery, Description and Integration (UDDI)
La especificación UDDI define SOAP basados en servicios Web para la
localización de protocolos de formato WSDL de servicios web. Este
esencialmente describe un registro electrónico en línea que sirve como electronic
Yellow Pages, proporcionando una estructura de información donde varios
registros de negocios y servicios ofrecen sus definiciones WSDL. Esto esta
basado en estándares de la industria incluyendo HTTP, XML, esquema XML,
SOAP y WSDL. Hay dos tipos de registros UDDI: registros públicos los cuales
sirven como puntos de agregación para una variedad de negocios publiquen sus
servicios y registros privados que tienen un rol similar interno en las
organizaciones. Existe un esfuerzo entre la industria conducido a todas las
plataformas principales y vendedores de software, incluyendo Fujitsu, HP,
Hitachi, IBM, Intel, Microsoft, Oracle/Sun, SAP así como otros contribuyentes
dentro del consorcio OASIS (Organization for the Advancement of Structured
Information Standards). La siguiente figura muestra la relación entre WSDL y
UDDI.
Relación entre WSDL y UDDI
Web Services
Web Service directory (UDDI)
2. Publish WSDL
XML interface
(WSDL) Documents
1. Generate
SOAP
internet 3. Find
XML interface
4. Invoke (WSDL)
Client application
UDDI
La especificación UDDI 3.0 define un modelo de información
compuesto de instancias de estructuras de datos persistentes
llamadas entities, las cuales son expresadas en XML y
almacenadas persistentemente por nodos UDDI. Están soportados
los siguientes tipos de entity (UDDI.org, 2004):
businessEntity, el cual describe una organización que
típicamente proporciona servicios web, incluyendo su nombre,
descripción del negocio, lista de contactos y una lista de
categorizaciones tales como industria, categoría de producto o
localización geográfica.
businessService, la cual describe una colección de servicios de
web ofrecidos por una businessEntity, que contiene información
descriptiva del servicio de negocio sobre un grupo o servicios
técnicos relacionados incluyendo el nombre del grupo, breve
descripción, información de enlace de soporte técnico, e
información de categorías o procesos de negocio que permiten a
UDDI buscar y descubrir servicios de web mas eficientemente.
UDDI
bindingTemplate, el cual describe la información técnica necesaria para
utilizar un businessService particular. Esto incluye un accessPoint
utilizado para transmitir la dirección de red correcta para invocar el
servicio web siendo descrito, la cual puede ser una URL, dirección de
correo, o inclusive un numero de teléfono.
tModel (technical model), el cual representa un concepto reutilizable, tal
como el tipo de servicio web, un protocolo utilizado por los servicios
web, o una categoría o un sistema, haciendo mas fácil para los
consumidores del servicio web encontrar estos servicios que sean
compatibles con una especificación técnica en particular. Cada
especificación distinta, transporte, protocolo o namespace esta
representado por el tModel. Ejemplos de tModel son definiciones de
esquema WSDL y XML (XDS) y otros documentos que perfilan y
especifican el contrato y comportamiento que un servicio web puede
cumplir. Por ejemplo, para enviar una orden de compra, el servicio que
se debe llamar debe conocer no solo la URL de el mismo, también que
formato deberá tener la orden de compra a ser enviada, que protocolos
son apropiados, que seguridad es requerida y que forma de respuesta
resultará después de enviar la orden.
UDDI
publisherAssertion, el cual describe la relación de un businessEntity con otro
businessEntity.
subscription, la cual describe un requerimiento estándar a hacer un seguimiento
a los cambios de las entities descritas por los subscription.
Entities pueden opcionalmente firmarse utilizando firmas digitales XML. Esta
información proporcionada por el registro UDDI puede ser utilizada para
realizar tres tipos de búsquedas:
White Pages search conteniendo direcciones, contacto e identificadores
conocidos. Por ejemplo, la búsqueda de un negocio por su nombre o un
identificador único.
Yellow Pages search contiene categorizaciones industriales basadas en
taxonomías estándar, tales como the North American Industry Classification
(NAICS), United Nations Standard Products and Services Code System
(UNSPSC), o the ISO Country codes classification systems (ISO 3166).
Green Pages search contiene información técnica sobre servicios web que
están expuestos por una organización, incluyendo referencias a
especificaciones de interfaces para servicios web, así como soporte para
apuntadores a varios archivos y mecanismos de descubrimiento basado en
URL.
Ejemplo de entrada UDDI
<businessEntity xmlns=“urn:uddi-org:api”
businessKey=“AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA”>
<name>Dream Home Estate Agents</name>
<description xml:lang=“en”>Estate Agents</description>
<businessServices>
<businessService
businessKey=“AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA”
serviceKey=“BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBB”
<name>Credit Bank</name>
<bindingTemplates>
<bindingTemplate
serviceKey=“BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBB”
bindingKey=“CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCC”
<accessPoint URLType=“https”>https://dreamhome.com.uk/credit.aspx</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo>tModelKey=“UUID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX”/>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
</businessService>
</businessServices>
<categoryBag>
<keyedReference tModelKey=“UUID:MK12345-678ª-9123-B456-/ABCDEFG8901”
keyName=“Credit check service”keyValue=“12.34.56.01.00”/>
</categoryBag>
</businessEntity>
XML Schema
Aunque XML 1.0 proporciona mecanismos DTD para la definición del modelo
contenido (el orden valido y el anidado de elementos) y en un alcance limitado,
los tipos de datos de los atributos del documento XML tienen algunas
limitaciones:
Están escritos con diferente sintaxis (no XML)
No tiene soporte para namespaces
Solo ofrece tipos de datos muy limitados.
Por lo tanto se necesita un método de definición de modelo contenido de un
documento XML mas exhaustivo y riguroso. El esquema W3C XML supera estas
limitantes y es mas expresivo que DTD (W3C, 2004a, b). La expresividad
adicional proporciona intercambio de información mas robusto entre
aplicaciones web y datos XML sin confiar demasiado en herramientas de
validación externas. Un esquema XML es la definición (en términos de
organización y tipo de datos) de una estructura especifica XML. El lenguaje W3C
XML schema especifica como cada tipo de elemento en el esquema esta definido
y que tipo de dato esta asociado a el. El esquema es por si mismo, un documento
XML, usando elementos y atributos para expresar la semántica del esquema.
Como es un documento XML puede editarse y procesarse por las mismas
herramientas que leen XML.
XML Schema
Tipos de datos incorporados en el esquema XML
El esquema XML incorpora los siguientes tipos de datos:
boolean, el cual contiene uno de dos valores true o false.
string, el cual contiene cero o mas caracteres Unicode, string tiene los
siguientes subtipos:
- normalizedString, para cadenas de caracteres que no contienen
caracteres en blanco excepto el carácter de espacio;
- token, un subtipo de normalizedString, para cadenas de caracteres
que no tienen espacios al inicio ni al final y no tienen dos o mas
espacios en un renglón;
- Name, un subtipo de token, el cual representa nombres XML, con
subtipos NCName, el cual representa un nombre XML sin dos puntos
y NMTOKEN;
- ID, IDREF e IDENTITY, subtipos de NCName, para los
correspondientes tipos de atributo;
- IDREF, NMTOKEN
XML Schema
• decimal, el cual contiene números reales en base 10 con subtipo
integer, para valores sin parte fraccional. Este subtipo tiene subtipos
de nonPositiveinteger, long y negativeInteger. Otros tipos dentro de
esta jerarquía incluyen int, short, y byte.
• float, para números binarios IEEE de 32 bits de punto flotante y
double, para números binarios IEEE de 64 bits de punto flotante.
• date, el cual contiene fechas en el formato yyyy-mm-dd; time, el cual
contiene hora en formato de 24 horas; dateTime, la combinación de
los dos antriores, por ejemplo 1945-10-01T23:10.
• Otros tipos de datos relacionados con fechas son duration, gDay,
GMonth, gYear. para calendario.
• QName, un nombre consistente en un namespace y un nombre local.
• anySimpleType el cual es la unión de todos los tipos primitivos.
• AnyType, el cual es la unión de todos los tipos (simples y complejos).
XML Schema
Tipos simples y complejos
Aun cuando es fácil crear un esquema XML, este sigue una estructura de
documento y define cada elemento como se encuentra. Elementos que
contienen otros elementos son de un tipo complexType. Para el elemento
raíz de nuestro ejemplo STAFFLIST, podemos definir un elemento
STAFFLIST para que sea un complexType. La lista de hijos del elemento
STAFFLIST, esta descrita por un elemento sequence (un compositor que
define una secuencia ordenada de elementos):
<xs:element name = “STAFFLIST”>

<xs:complexType>
<xs:sequence>
<!– children defined here -->
</xs:sequence>
</xs:complexType>
</xs:element>
XML Schema
Cada uno de los elementos en el esquema tiene un prefijo xs:,

el cual es asociado a W3C XML Schema namespace
através de la declaración xmlns:xs =
http://www.w3.org/2001/XMLSchema (el cual esta colocado
en el elemento schema) STAFF y NAME también contienen
subelementos y podría ser definido en forma similar.
Elementos sin subelementos o atributos son del tipo
simpleType. por ejemplo, podemos definir STAFFNO, DOB,
y SALARY como sigue:
<xs:element name = “STAFFNO” type = “xs:string”/>
< xs:element name = “DOB” type = “xs:date”/>
< xs:element name = “SALARY” type = “xs:decimal”/>
XML Schema
XML Schema
Los elementos son declarados utilizando los tipos predefinidos W3C
XML Schema de string, date y decimal, respectivamente otra vez con el
prefijo xs: para indicar que pertenecen a un vocabulario XML Schema.
Podemos definir el atributo branchNo, el cual es como sigue:
<xs:attribute name = “branchNo” type = “xs:string”/>
Cardinalidad
El W3C XML Schema proporciona la cardinalidad de un elemento a ser
representado utilizando atributos minOccurs (el mínimo numero de
ocurrencias) y maxOccurs (el máximo numero de ocurrencias). Para
representar a un elemento opcional, colocamos maxOccurs en 0; para
indicar que no hay un numero máximo de ocurrencias, colocamos
maxOccurs con el termino unbounded. Si no se especifica, el valor por
default de cada atributo es 1. Por ejemplo, como DOB es un elemento
opcional, se representa de la siguiente manera:
<xs:element name = “DOB” type = “xs:date” minOccurs=“0”/>

XML Schema
Si también queremos registrar los nombres de hasta tres familiares por cada
miembro del personal, queremos representar esta usando:
<xs:element name = “NOK” type = “xs:string” minOccurs = “0” maxOccurs =
“3”/>
References
Un enfoque alternativo el cual esta basado en utilizar referencias a los elementos
y las definiciones de los atributos que necesitan estar dentro del alcance del
referenciador. Por ejemplo, podemos definir a STAFFNO como:
<xs:element name = “STAFFNO” type = “xs:string”/>
Y utilizar esta definición en la siguiente forma en el esquema cuando se requiera
el elemento STAFFNO:
<xs:element ref = “STAFFNO”/>
Si hay muchas referencias a STAFFNO en el documento XML, utilizando
referencias se colocará la definición una vez y por lo tanto mejorar el
mantenimiento del esquema.
XML Schema
Definiendo nuevos tipos

El esquema XML proporciona un tercer mecanismo para crear
elementos y atributos basados en la definición de nuevos tipos. Esto es
análogo a la definición de clases y su utilización para crear un objeto. Se
pueden definir tipos simples y complejos para elementos PCDATA o
atributos. Por ejemplo, se puede definir un nuevo tipo para el elemento
STAFFNO como sigue:
<xs:simpleType name = “STAFFNOTYPE”>
<xs:restriction base = “xs:string”>
<xs:maxLength value = “5”/>
</xs:restriction>
</xs:simpleType>
XML Schema
Este nuevo tipo ha sido definido como una restricción del

tipo de datos string del namespace del esquema XML
(atributo base) y también se especifica que tiene una longitud
máxima de 5 caracteres (el elemento maxLength es llamado
una faced). El esquema XML define 15 facets incluyendo
length, minLength, minInclusive y maxInclusive. Otros dos
particularmente útiles son pattern y enumeration. El
elemento pattern define una expresión regular que debe
coincidir. Por ejemplo STAFFNO esta obligado a tener dos
caracteres en mayúsculas seguidos por entre uno y tres
dígitos (como SG5, SG37, SG999), esto se puede representar
de la siguiente manera:
XML Schema
<xs:pattern value = “[A-Z]{2}[0-9]{1,3}”>
El elemento enumeration limita un tipo simple a un

conjunto de valores distintos. Por ejemplo, POSITION
esta obligado a tener solo valores Manager, Supervisor
o Assistant y lo representamos de la siguiente manera:
<xs:enumeration value = “Manager”/>

<xs:enumeration value = “Supervisor”/>
<xs:enumeration value = “Assistant”/>
XML Schema
Grupos
El W3C XML Schema proporciona la definición de
grupos de elementos o atributos. Un grupo no es un tipo
de datos pero actúa como un contenedor con un
conjunto de elementos o atributos. Por ejemplo:
<xs:group name = “STAFFTYPE”>

<xs: sequence>
<xs:element name = “STAFFNO” type = “STAFFNOTYPE”/>
<xs:element name = “POSITION” type = “POSITIONTYPE”/>
<xs:element name = “DOB” type = “xs:date”/>
<xs:element name = “SALARY” type = “xs:decimal”/>
</xs:secuence>
</xs:group>
XML Schema
Esto crea un grupo llamado STAFFTYPE como una

secuencia de elementos. También se puede crear un
elemento STAFFLIST para referenciar el grupo como
una secuencia de cero o mas STAFFTYPE como sigue:
<xs:element name = “STAFFLIST”>
<xs:complexType>
<xs:sequence>
<xs:group ref = “STAFFTYPE” minOccurs = “0”
maxOccurs = “unbounded”/>
</xs:secuence>
</xs:complexType>
</xs:element>
XML Schema
Choice y all compositors
La secuencia es un ejemplo de compositor. Hay otros dos tipos de compositor: choice
y all. El compositor choice define una elección entre varios elementos posibles o
grupos de elementos y el compositor all define un conjunto de elementos no
ordenados. Por ejemplo, se puede representar la situación en donde los nombres del
equipo de trabajo puede ser una sola cadena de caracteres o una combinación de
nombre y apellido:
<xs:group name = “STAFFNAMETYPE”>

<xs:choice>
<xs:element name = “NAME” type = “xs:string”/>
<xs:sequence>
<xs:element type = “FNAME” type = “xs:string”/>
<xs:element type = “LNAME” type = “xs:string”/>
</xs:secuence>
</xs:choice>
</xs:group>
XML Schema
Lists and unions
Se pueden crear una lista de objetos utilizando el elemento list. Por ejemplo:
<xs:simpleType name = “STAFFNOLIST”>

<xs:list itemType = “STAFFNOTYPE”/>
</xs:simpleType>
Y utilizar este tipo en un documento XML como sigue:

<STAFFNOLIST> “SG5” “SG37” “SG999” </STAFFNOLIST>
Y ahora podemos derivar un nuevo tipo de el tipo list

<xs:simpleType name “STAFFNOLIST10”>
<xs:restriction base = “STAFFNOLIST”>
<xs:Length value = “10”/>
</xs:restriction>
</xs:simpleType>
XML Schema
Los tipos atómicos y list proporcionan a un elemento o al valor de un
atributo tener una o mas instancias de un tipo atómico. En contraste, el tipo
unión habilita a un elemento o atributo a tener una o mas instancias de un
tipo seleccionado de la unión de múltiples tipos atómicos o list. El formato
es similar a choice.
Constraints
El W3C XML Schema también proporciona características XPath para
uniqueness constraints específicos. Revisaremos dos tipos de contraints:
uniqueness constraints y key constraints
Uniqueness constraints
Para definir un uniqueness constraint, se debe especificar un elemento
unique que defina los elementos o atributos que son únicos. Por ejemplo se
puede definir un uniqueness constraint con nombre, apellido y fecha de
nacimiento:
XML Schema
<xs:unique name = “NAMEDOBUNIQUE”>
<xs:selector xpath = “STAFF”/>
<xs:field xpath = “NAME/LNAME”/>
<xs:field xpath = “DOB”/>
</xs:unique>
La posición del elemento único en el esquema proporciona el contexto del

nodo en el cual se coloca el constraint. Colocando este constraint bajo el
elemento STAFF, se pueden especificar que el constraint es único dentro del
contexto del elemento STAFF y es análogo a especificar un constraint en una
relación en una RDBMS.
Key constraints
Es similar al uniqueness constraint excepto que el valor debe ser no nulo.
Este tambien proporciona la llave a ser referenciada. Por ejemplo:
XML Schema
<xs:key name = “STAFFNOISKEY”>

<xs:field xpath = “STAFFNO”/>
</xs:key>
Un tercer tipo de constraint permite referencias hacia su llave especifica. Por

ejemplo:
<xs:keyref name = “BRANCHNOREF” refer “BRANCHNOISKEY>

<xs:field xpath = “@branchNo”/>
</xs:keyref>
Resource Description Framework (RDF)
Aunque un esquema XML proporciona un método mas

exhaustivo y riguroso para la definición del modelo
contenido de un documento XML los DTD no proporcionan
el soporte semántico interoperable que se requiere. Por
ejemplo, cuando dos aplicaciones intercambian información
utilizando XML, ambas acuerdan el uso y el significado de la
estructura del documento, sin embargo antes de que esto
pase, un modelo del dominio de interés se debe construir
para clarificar que tipo de información se enviará desde la
primera aplicación hacia la segunda. Este modelo es
generalmente descrito en términos de objetos o relaciones.
Sin embargo, como el esquema XML solo describe la
gramática, hay muchas formas de codificar un modelo
especifico de el esquema.
En este caso no es suficiente “mapear” un esquema XML hacia otro. Por
lo tanto se requieren realizar los siguientes tres pasos:
realizar una re-ingeniería del modelo original del esquema XML
definir mapas entre los objetos en los modelos
definir mecanismos de traducción para los documentos XML, por
ejemplo utilizando XSLT.
El Resource Description Framework (RDF) desarrollado bajo el auspicio
de W3C es una infraestructura que habilita la codificación, intercambio y
reuso de metadata estructurado (W3C, 1999d, 2004c). Esta
infraestructura habilita la interoperabilidad de metadata, a través del
diseño de mecanismos que soportan convenciones comunes de
semántica, sintaxis y estructura. RDF no manipula la semántica para
cada dominio, en lugar de esto, proporciona la habilidad para que estos
dominios definan elementos de metadata como se requieran. RDF utiliza
XML como una sintaxis en común para el intercambio y procesamiento
de metadata. Explotando las características de XML, RDF impone una
estructura que proporciona las expresiones de semántica y habilita la
descripción consistente e intercambio de metadata estándar.
Modelo de datos RDF

El modelo básico de datos RDF consiste de tres objetos:
Resource: es cualquier cosa que pueda tener una URI, por
ejemplo, una pagina web, un numero de paginas web, parte de
una pagina web, el cual es tratado como un elemento XML.
Property, el cual es un atributo especifico utilizado para
describir un recurso. Por ejemplo, el atributo Autor puede
utilizarse para describir quien genero un documento XML en
particular.
Statement, el cual consiste en la combinación de un resource,
una property y un valor. Estos componentes son conocidos
como el “sujeto”, el “predicado” y el “objeto” de una sentencia
RDF. Por ejemplo: “The Author of
http://www.dreamhome.com.uk/staff_list.xml is John White”
La sentencia anterior se puede expresar de la siguiente manera:
<rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:rdf=“http://www.dreamhome.com.uk/schema/”>
<rdf:Description about =
http://www.dreamhome.com.uk/staff_list.xml>
<s:Author> John White </s:Author>
</rdf:Description>
</rdf:RDF>
Se puede representar esto en un diagrama utilizando la grafica etiquetada
mostrada en la siguiente figura. Si se quisiera almacenar información
descriptiva sobre el autor, se tiene el siguiente fragmento XML
<rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:rdf=“http://www.dreamhome.com.uk/schema /”>
<rdf:Description about = http://www.dreamhome.com.uk/staff_list.xml>
<s:Author
rdf:resource=http://www.dreamhome.com.uk/Author_001”/>
</rdf:Description>
<rdf:Description about =http://www.dreamhome.com.uk/Author_001”>
<s:Name>John White</sName>
<s:e-mail>white@dreamhome.com.uk</s:e-mail>
<s:position>Manager</s:position>
</rdf:Description>
</rdf:RDF>
Representación de Author como property
Author
staff_list.xml “John White”
Representación de Author como resource
Author Author_001
staff_list.xml position
Name Manager
e-mail
“John White” white@dreamhome.com.uk

Notation3 (N3) and Turtle

Notation3 o N3 como es mas comúnmente conocido es un
subconjunto serializable no XML de un modelo RDF que es
mas compacto y entendible que la notación XML RDF. El
formato esta siendo desarrollado por Tim Berners-Lee y
otras personas del Semantics Web community. N3 soporta
algunas características mas allá de serialization de modelos
RDF, tales como soporte de reglas basadas en RDF. Turtle
es un subconjunto de N3 mas simple de RDF. En N3 y turtle,
las sentencias estan escritas como triple consistencias del
sujeto URI seguidas por el predicado URI después el objeto o
valor literal y finalmente un punto.
Por ejemplo:
@prefix rdf:<http:// www.w3.org/1999/02/22-rdf-syntax-ns#”>.
@prefix s:< http://www.dreamhome.com.uk/schema>.
< http://www.dreamhome.com.uk/staff_list.xml>
s:Author < http://www.dreamhome.com.uk/Author_001>.
< http://www.dreamhome.com.uk/Author_001> s:Name “John White”.
< http://www.dreamhome.com.uk/Author_001>.
s:e-mail “white@dreamhome.com.uk”.
< http://www.dreamhome.com.uk/Author_001> s:position “Manager”.
RDF Schema
Especifica información sobre las clases en el esquema incluyendo propiedades y atributos
y la relación entre recursos (clases). Más específicamente, el mecanismo de Esquema RDF
proporciona un tipo básico system para el uso de modelos RDF análogo al esquema XML.
Este define recursos y propiedades tales como rdfs:Class y rdfs:subClassOf que son
utilizados en aplicaciones especificas con esquemas específicos. Esto también proporciona
una facilidad para especificar un pequeño numero de constraints tales como de
cardinalidad requeridos y permiten las propiedades de instancias de clases.
Un esquema RDF especifica un lenguaje declarativo

influenciado por ideas de la representación del
conocimiento (por ejemplo, redes semánticas y lógica de
predicados). Así como la representación de modelos de
un esquema en una base de datos tales como modelos
binarios relacionales, por ejemplo, NIAM (Nijssen y
Halpin, 1989) y modelos de graficas de datos.
SPARQL
SPARQL (Simple Protocol and RDF Query Language) es un lenguaje de
consultas RDF que ha sido desarrollado por el RDF Data Access Working
Group (DAWG) del W3C y es considerado un componente del Semantic
Web (W3C, 2008). Como se vio anteriormente RDF esta construido por
una tripleta o 3-upla consitente de sujeto, predicado y objeto . En la
misma forma , esta construido en el triple patrón, el cual consiste
tambien en sujeto, predicado y objeto. Por ejemplo:
Regresar el nombre y email del autor

SELECT ?name, ?e-mail
FROM <http://www.dreamhome.com.uk/staff_list.rdf>
WHERE {
?x ?s:Name ?name.
?x ?s:email ?e-mail.
}
SPARQL
La clausula SELECT es utilizada para definir el data item que

será regresado por la consulta. En el ejemplo, se regresan dos
items: el nombre del autor y su correo electronico.
Ejemplo 2:
SELECT ?name, ?e-mail, ?telNo

FROM <http://www.dreamhome.com.uk/staff_list.rdf>
WHERE {
?x ?s:Name ?name.
?x ?s:email ?e-mail.
OPTIONAL { ? ?s:telNol ?telNo. }
}
ORDER BY ?name
SPARQL
Ejemplo 3:
SELECT ?name
FROM
<http://www.dreamhome.com.uk/staff_list.rdf>
WHERE {
?x ?s:Name ?name.
?x ?s:position ?position.
FILTER { ?position = “Manager” || ?position =
“Assistant”. }
}
XML Query Languages
XML Query Languages

Existen algunos lenguajes de consulta para datos semi
estructurados que pueden ser utilizados para consultar
documentos XML incluyendo XML-QL (Deutsch et. al.,
1998), UnQL (Buneman et. al., 1996) y XQL de Microsoft
(Robie et. al., 1998). Estos lenguajes tienen una notación de
una expresión “path” para navegar en la estructura anidada
del XML. Por ejemplo XML-QL utiliza la estructura anidada
XML para especificar la parte de un documento a ser
seleccionado y el resultado de la estructura XML. Para
encontrar el apellido del staff que gana mas de £30,000. Se
podrá utilizar el siguiente query:
XML Query Languages
WHERE <STAFF>
<SALARY>$S<SALARY>
<NAME><FNAME>$F</FNAME><LNAME>$L</LNAME></NAME>
</STAFF> IN http://www.dreamhome.com.uk/staff.xml
$S>30000
CONSTRUCT <LNAME>$L</LNAME>
Aun cuando hay diferentes enfoques solo nos concentraremos en dos:

Como el Lore Data Model y Lorel query language se han extendido para manejar XML;
el trabajo de W3C XML Query Working Group
Lore es un database management system (DBMS) para XML. El proyecto Lore se ha

enfocado en definir un lenguaje de consulta declarativo para XML, desarrollando nueva
tecnologia para busquedas interactivas sobre datos XML, y construyendo un eficiente
procesador de consultas XML. Lore ha estado en desarrollo en la Universidad de Stanford
desde 1995. Lore fue desarrollado originalmente para un modelo de datos llamado OEM;
OEM este es esencialmente equivalente a XML, pero OEM no soporta la notación de
DTDs. Por lo tanto, gran parte del trabajo inicial se orientó a la suposición de que los
datos son semi estructurados y no necesitan conformar un esquema particular.
Recientemente se migró Lore para soportar completamente a XML
Lore y Lorel
Lore (Lightweight Object Repository) es un DBMS

multiusuario, el cual soporta recuperación en caso de
desastres, vistas materializadas, carga masiva de archivos en
algunos formatos estándar (esta soportado XML) y un
lenguaje declarativo de actualizaciones. Lore también tiene
un administrador de datos externo que habilita información
de fuentes externas para ser extraídas dinámicamente y
combinadas con la información local durante el
procesamiento de las consultas.
Asociado con Lore esta Lorel (the Lore Language) una
extensión de un lenguaje de consulta de objetos.
Lorel fue creado para manejar lo siguiente:
Lore y Lorel
consultas que regresan resultados validos aun cuando alguna
información no este disponible;
consultas que operan uniformemente sobre valores simples y
conjuntos de datos;
consultas que operan uniformemente sobre información de distintos
tipos;
consultas que regresan objetos heterogeneos;
consultas donde la estructura de los objetos no es completamente
conocida.
Lorel soporta expresiones declarativas “path” para navegar en
estructuras path y coerción automática para manejar datos heterogéneos
y sin tipo.
Una expresión path es esencialmente una secuencia de etiquetas (L1,
L2, ..., Ln), el cual produce un conjunto de nodos para una grafica dada.
Para el siguiente ejemplo la expresión path produce un conjunto de
nodos
DremHome.PropertyForRent {&5, &6}
Lore y Lorel
SELECT s.Oversees
FROM DreamHome.Staff s
WHERE s.name = “Ann Beech”
Answer
PropertyForRent &5
street &11 “2 Manor Rd”
type &12 “Flat”
monthlyRent &13 375
OverseenBy &4
PropertyForRent &6
street &14 “18 Dale Rd”
type &15 1
annualRent &16 7200
OverseenBy &4
Este resultado es empacado dentro de un solo objeto complejo con la etiqueta default Answer. El
objeto Answer se convierte en un nuevo objeto en la base de datos, el cual puede ser consultado en la
forma normal.
Extensiones Lore y Lorel para manejar XML
En Lore basado en el modelo XML, un elemento XML es un par (eid, value)
donde eid es un identificador de un elemento único y value es una cadena de
caracteres o un valor complejo conteniendo uno de los siguientes:
una etiqueta correspondiente a una etiqueta XML para ese elemento;
una lista ordenada de nombres de atributos y valores pares, con el valor
un tipo base (por ejemplo, integer, string) o un ID, IDREF o IDREFS;
una lista ordenada de elementos entrelazados de la forma (label, eid)
donde label es una cadena (los subelementos entrelazados son
introducidos utilizando IDREF o IDREFS);
una lista normal de subelementos de la forma (label, eid) donde label es
un string (subelementos normales que son introducidos utilizando
anidamiento léxico dentro del documento XML)
Los comentarios y espacios en blanco entre elementos etiquetados son
ignorados y la sección de CDATA son trasladados dentro de elementos
atómicos de texto. En la siguiente figura se ilustra el mapa del documento
XML de la pagina 33.
Un documento XML en Lore
DREAMHOME
&1 BRANCH
STAFF
STAFF
{staffNo=“ SL21”}
staff
&2 {staffNo=“ SL41”} &3 &4 {staff=“SL21 SL41”}
staff
NAME NAME BRANCHNO
&5 &6 &7

FNAME LNAME
text text
&9 &10
&8 &11
text text
B005
“John White”
&12 &13
“Julie” “Lee”
Lorel
Lorel
El concepto de path expression ha sido extendido en la versión
XML de Lorel que permite la navegación de ambos atributos y
subelementos distinguiéndose por un calificador de expresión
path (“>” solo para emparejar subelementos y “@” para atributos).
Cuando no se da un calificador ambos atributos y subelementos
son emparejados. En resumen, Lorel ha sido extendido para que
las expresiones [range] puedan opcionalmente ser aplicadas a
cualquier componente o variable de expresión path (range es una
lista números simples y/o range, tales como [1-3, 7].
SELECT s.NAME.LNAME
FROM DREAMHOME.STAFF s
WHERE s.SALARY > 30000
XML Query Working Group

W3C formó el XML Query Working Group en 1999 para
producir un modelo de datos para documentos XML, un
conjunto de operadores de consulta en este modelo y un
lenguaje de consultas basado en los operadores de consulta.
Las consultan operan en un solo documento o en colecciones
de estos, y pueden seleccionar todo el documento o sub
arboles de documentos que coincidan con las condiciones
basándose en el contenido y la estructura del mismo. Las
consultas también pueden construir nuevos documentos
basándose en que se ha seleccionado. Al final, la colección de
documentos XML pueden ser accesados como bases de
datos.
Varias comunidades han contribuido a la especificación de
XQuery:
La comunidad de base de datos ha proporcionado su experiencia
en diseñar lenguajes de consulta y técnicas de optimización para
aplicaciones con datos intensivos. Tales aplicaciones centradas
en datos (datacentrics) generalmente requieren operaciones de
actualización y recuperación en bases de datos muy grandes
potencialmente. XQuery incorpora características de lenguajes
de consulta de sistemas relacionales (SQL) y orientados a
objetos (OQL).
La comunidad de lenguajes de programación ha proporcionado
su experiencia en el diseño de lenguajes funcionales, tipos de
sistemas, y utilización de lenguajes de especificación formal.
XQuery es un lenguaje funcional con un tipo de sistema estático
basado en XML Schema. Se ha incluido semántica formal como
parte integral de la especificación XQuery.
Algunos documentos producidos por el XML Query Working

Group son los siguientes:
XML Query (XQuery) Requirements;
XML XQuery 1.0 and XPath 2.0 Data Model;
XML XQuery 1.0 and XPath 2.0 Formal Semantics;
XQuery 1.0-An XML Query Language;
XQuery 1.0 and XPath 2.0 Functions and Operators;
XSLT 2.0 and XQuery 1.0 Serialization; XQuery Update
Facility.
Los requerimientos del XML Query especifican metas,
escenarios de utilización y requerimientos para el W3C
Query Data Model y Query Language algunos de estos
requerimientos son:
El lenguaje debe ser declarativo y debe ser definido

independientemente de cualquier protocolo en donde sea
utilizado;
El modelo de datos debe representarse por XML 1.0
character data y tipos de datos simples y complejos de la
especificación del esquema XML; tambien debe incluir
soporte para referencias dentro y fuera del documento;
Las consultas deberán ser posibles exista o no el esquema;
El lenguaje debe soportar calificadores universales y
existenciales en las colecciones y debe soportar
aggregation, clasificación, nulls y debe tener la habilidad
para navegar dentro y fuera de referencias de documentos.
XQuery A Query Language for XML
XQuery- A Query Language for XML

El W3C Query Working Group ha propuesto un lenguaje de consultas
para XML llamado XQuery (W3C, 2007f). XQuery se deriva de un
lenguaje de consulta XML llamado Quilt (Chamberlain et. al., 2000),
el cual tomo características prestadas de muchos otros lenguajes tales
como XPath, XML-QL, OQL, Lorel, XQL y YATL (Cluet et. al., 1999).
Como OQL, XQuery es un lenguaje funcional en el cual una consulta
es representada como una expresión. El valor de una expresión es
siempre una secuencia (sequence), la cual es una colección ordenada
de uno o mas valores atómicos o nodes; un valor atómico es un solo
valor que corresponde a un tipo simple definidos en XML, un node
puede ser un documento, elemento, atributo, texto, namespace,
instrucción de procesamiento o comentario. XQuery soporta varios
tipos de expresiones, las cuales pueden ser anidadas (soportando la
notación de un subquery).
Path expressions
Xquery Path expressions usan la sintaxis de XPath. En XQuery el
resultado de una path expression esta a razón de una lista de nodos,
incluyendo sus nodos descendientes. El resultado de los nodos al nivel
superior en la path expression son ordenados de acuerdo a su posición
en la jerarquía original en orden top-down, left-to-right. El resultado
de una path expression puede contener valores duplicados, esto es,
nodos múltiples con el mismo tipo y contenido.
Cada step en el path expression representa movimientos a través del
documento en una dirección en particular y cada step puede eliminar
nodos aplicando uno o mas predicados. El resultado de cada step es
una lista de nodos que sirven como un punto inicial para el siguiente
step. Una expresión path puede iniciar con una expresión que
identifica un nodo, tale como la función doc(string), la cual regresa
el nodo raíz de un documento. Una consulta también puede contener

una expresión path iniciando con “/” o “//”, las cuales representan un
nodo raíz implícito determinado por el medio ambiente en el cual el
query es ejecutado.
Ejemplo:
(1) Encuentre el staff number del primer miembro del staff en el
documento XML del ejemplo 1 pagina 26:
doc(“staff_list.xml”)/STAFF[1]/STAFFNO or
doc(“staff_list.xml”)/STAFFLIST/STAFF[1]/STAFFNO
(2) Encuentre los staff numbers de los primeros dos elementos de staff
doc(“staff_list.xml”)/STAFFLIST/STAFF[1 TO 2]/STAFFNO
(3) Encuentre los apellidos del staff en la sucursal B005
doc(“staff_list.xml”)/STAFFLIST/STAFF[@branchNo = “B005”]/LNAME
Ejemplo 1 de XML
<?xml version=“1.1” encoding=“UTF-8” standalone=“no”?>
<?xml:stylesheet type = “text/xsl” href = “staff_list_xsl”?>
<!DOCTYPE STAFFLIST SYSTEM “staff_list_dtd”>
<STAFFLIST>
<NAME>
</NAME>
<DOB>1945-10-01</DOB>
</STAFF>

<NAME>
</NAME>
<POSITION>Assitant</POSITION>
</STAFF>
</STAFFLIST>
FLWOR expressions
Una expresión FLWOR esta construida por clausulas FOR, LET, WHERE, ORDER
BY y RETURN. La sintaxis de la expresión FLWOR es la siguiente:
FOR forVar IN inExpression

LET letVar := letExpression
[WHERE filterExpression]
[ORDER BY orderSpec]
RETURN expression
Una expresión FLWOR inicia con una o mas clausulas FOR o LET en cualquier
orden, seguido por una clausula WHERE opcional, una clausula ORDER BY
también opcional y una clausula requerida RETURN. Como en un query SQL estas
clausulas deben aparecer en orden, como se muestra en la siguiente figura. Una
expresión FLWOR une valores a una o mas variables y entonces utiliza estas variables
para construir un resultado. Una combinación de variables enlaza clausulas creadas
por FOR y LET la cual es llamada tupla.
Flujo de datos en una expresión FLWOR
FOR / LET
clauses
list of tuples of bound variables
WHERE clause
(optional)
restricted list of tuples of bound variables
ORDER BY clause
(optional)
sort the tuples in the tuple stream
RETURN clause
instance of XML query data model

FLWOR Expressions
Ejemplo
1. Listar el staff con un sueldo de £30,000
LET $SAL := 30000
RETURN doc(“staff_list.xml”)//STAFF[SALARY = $SAL]
En este ejemplo la simple extensión de una expresión path con una variable utilizada
para representar el valor del sueldo que se quiere restringir. Para el ejemplo 1 solo un
elemento STAFF satisface el predicado, así que el resultado es el siguiente:

<NAME><FNAME>John</FNAME><LNAME>White</LNAME>
</NAME>
<DOB>1945-10-01</DOB>
</STAFF>
FLWOR Expressions
Nótense dos puntos interesantes en el query:

El predicado parece comparar un elemento (SALARY) con un valor
(30000). De hecho el operador “=“ extrae el valor escrito del
elemento resultante en un valor decimal, el cual es entonces
comparado con 30000.
El operador “=“ es llamado general comparison operator. XQuery
también define value comparison operators (“eq”, “ne”, “lt”, “le”,
“gr”, ”ge”), los cuales son utilizados para comparar dos valores
atómicos. Si alguno de los operandos es un node, atomization, se
utiliza para convertirlo en un valor atomico (si alguno de los
operandos no tiene tipo, es tratado como un string). Si no se tiene
información disponible (por ejemplo el documento tiene un DTD en
lugar de un XML Schema), se necesitarían varios elementos para
convertir el elemento SALARY a su tipo apropiado:
xs:decimal(SALARY) gt $SAL
FLWOR Expressions
Si tratamos de comparar un valor atómico con una expresión que regrese
nodos múltiples, entonces un general comparison operator regresa “true” si
cualquier valor satisface al predicado; sin embargo, un value comparison
operator podría generar un error para este caso.
2. Liste el personal (staff) en la sucursal B005 con un salario mayor a
£15,000
FOR $S IN doc(“staff_list.xml”)//STAFF
WHERE $S/SALARY > 15000 AND $S/@branchNo = “B005”
RETURN $S/STAFFNO
En este ejemplo utilizamos la clausula FOR para esta repetición sobre los
elementos de STAFF en el documento y para cada uno, realizar la
comparación del elemento SALARY y el atributo branchNo. el resultado del
query será el siguiente:
FLWOR Expressions
El concepto de effective boolean value (EBV) es la clave para evaluar

expresiones logicas. el EBV de una secuencia vacia es falso; el EBV es
tambien falso si la expresión evalua a: el x:boolean valor falso, un cero, una
cadena de caracteres vacia o el valor especial flotante NaN (Not a Number);
el EBV de cualquier otra secuencia es verdadera.
3. liste todos los empleados, en orden descendente por staff number
ORDER BY $S/STAFFNO
DESCENDING
RETURN $S/STAFFNO
FLWOR Expressions
Este query utiliza la clausula ORDER BY para proporcionar el orden

requerido. El resultado del query es el siguiente:
4. Liste cada sucursal y el promedio del sueldo de los empleados que trabajan
de la misma
FOR $B IN distinct-values(doc(“staff_list.xml”)//@branchNo)
LET $avgSalary := avg(doc(“staff_list.xml”)//STAFF[@branchNo = $B]/SALARY)
RETURN
<BRANCH>
<BRANCHNO>{$B/text()}</BRANCHNO>
<AVGSALARY>$avgSalary</AVGSALARY>
</BRANCH>
FLWOR Expressions
5. Liste las sucursales que tienen mas de 20 empleados (staff)
<LARGEBRANCHES>
LET $S := doc(“staff_list.xml”)//STAFF[@branchNo = $B]
WHERE count($S) >20
RETURN
</LARGEBRANCHES>
FLWOR Expressions
6. Liste las sucursales que tienen al menos un miembro del staff con un
sueldo mayor a £15,000
<BRANCHESWITHLARGESALARIES>
LET $S := doc(“staff_list.xml”)//STAFF[@branchNo = $B]
WHERE SOME $sal IN $S/SALARY
SATISFIES ($sal > 15000)
RETURN
</BRANCHESWITHLARGESALARIES >
FLWOR Expressions
En este ejemplo se utiliza el existential quantifier SOME dentro de la
clausula WHERE para localizar las sucursales con al menos un empleado
que gane mas de £15,000. Tambien podemos utilizar el existential quantifier
EVERY.
En los siguientes ejemplos se observará como XQuery puede unir

documentos XML con las clausulas FOR y WHERE.
Se tiene el siguiente ejemplo nok( Next of Kin).xml
<NOKLIST>
<NOK>
<STAFFNO>SL21>/STAFFNO>
</NOK>
</NOKLIST>
FLWOR Expressions
Ejemplo: XQuery FLWOR expressions: joining two documents
(1) Liste el staff a través de los detalles de su siguiente pariente.
FOR $S IN doc(“staff_list.xml”)//STAFF,
$NOK IN doc(“nok.xml”)//NOK
WHERE $S/STAFFNO = $NOK/STAFFNO
RETURN <STAFFNOK> {$S, $NOK/NAME}</STAFFNOK>
La expresión FLWOR puede obligar una variable de la información staff y

otra del next of kin a comparar la información en ambos archivos y crear
resultados que combinen esta información. El resultado sera:
FLWOR Expressions
<STAFFNOK>
<STAFF branchNo = “B005”>
<NAME>
<NAME>
<DOB>1945-10-01</DOB>
</STAFF>
<NAME>Mrs. Mary White</NAME>
</STAFFNOK>
FLWOR Expressions
(2) Liste todo el staff con los detalles de sus parientes
FOR $S IN doc(“staff_list.xml”)//STAFF,
RETURN
<STAFFNOK>
{ $S
FOR $NOK IN doc(“nok.xml”)//NOK
WHERE $S/STAFFNO = $NOK/STAFFNO
RETURN $NOK/NAME
}
</STAFFNOK>
En este ejemplo se requiere listar los detalles de cada miembro del staff
independientemente que tenga parientes o no. En el modelo relacional, esto es
conocido como un Left Outer join
Resultado del XQuery del ejemplo anterior
<STAFFNOK>
<NAME>
</NAME>
<DOB>1945-10-01</DOB>
</STAFF>
<NAME>Mrs Mary White>/NAME>
</STAFFNOK>
<STAFFNOK>
<NAME>
</NAME>
<POSITION>Asistant</POSITION>
</STAFF>
</STAFFNOK>
FLWOR Expressions
(3) Liste cada sucursal y el staff que trabaja en la misma
<BRANCHLIST>
{
ORDER BY $B
RETURN
<BRANCHNO>{$B/text()}
{
WHERE $S/@branchNo = $B
ORDER BY $S/STAFFNO
RETURN $S/STAFFNO, $S/NAME, $S/POSITION, $S/SALARY
}
</BRANCHNO>
}
</BRANCHLIST>
XML Query Languages
Built-in functions y user-defined functions

Se han revisado algunas funciones en XQuery: doc(), disctinct-values(),
count() y avg(). Muchas otras estan definidas como:
Las otras funciones comunes aggregate min(), max(), sum();
funciones de cadenas de caracteres como, string-length(), starts-
with(), ends-with() y concat();
funciones numéricas como round(), floor() y ceiling();
otras funciones como not(), empty(), exists(), string() y data().
En resumen los usuarios pueden crear sus propias funciones utilizando

DEFINE FUNCTION, la cual especifica la firma de la función seguida por el
cuerpo de la misma encerrada en corchetes ( { } ). La firma de la función
proporciona una lista de parametros de entrada separados por comas
seguido del tipo de valor que regresa
XML Query Languages
Ejemplo:
Crear una función que regrese el staff de una sucursal dada
DEFINE FUNCTION staffABranch($branchnumber) AS element()*

{
WHERE $S/@branchNo = $branchnumber
ORDER BY $S/STAFFNO
RETURN $S/STAFFNO, $S/NAME, $S/POSITION, $S/SALARY
}
Esta función esta basada en el loop interno de uno de los ejemplos anteriores, ahora
el codigo se puede reemplazar por la función
staffABranch($B)
XML Query Languages
Asi XML permite estructuras recursivas. Esto se ilustra en la siguiente figura:
Module declaration
Library
declaration
Prolog Module
declaration
Query body
Las funciones pueden ser colocadas en library modules incluyendo la declaración

MODULE al inicio del modulo; por ejemplo:
MODULE “https://www.dreamhome.com.uk/library/staff_list”
XML Query Languages
El modulo puede importarse para consultas especificando el URI del mismo y
opcionalmente la localidad donde el modulo será encontrado, por ejemplo:
IMPORT MODULE “https://www.dreamhome.com.uk/library/staff_list”
AT file://C:/xroot/lib/staff_list.xq
Tipos y tipos de secuencia

Cada elemento o atributo en XQuery tiene un type annotation. Si el elemento ha
sido validado a través del XML Schema, tendrá el tipo especificado en este
esquema. Si un elemento no ha sido validado o no se le ha dado un type
annotation, se le da el type annotation default xs:anyType (o
xdt:untypedAtomic para un attribute node). Valores atómicos (nonnode) pueden
también tener type annotations. La annotation xdt:untypedAtomic indica que el
tipo es desconocido (típicamente texto crudo de un archivo schema-less XML).
Operaciones que toman valores atómicos pueden emitir uno de estos tipos para
un tipo mas especifico, tal como xs:string, pero si el valor atómico es del tipo
incorrecto se tendrá un error al tiempo de ejecución.
XML Query Languages
El valor de una expresión en XQuery es una secuencia y los tipos utilizados
para describirla son llamados secuence types.
Otras funciones incorporadas incluyen attribute(), document-node(),
text(), node() la cual iguala cada nodo, e item() la cual iguala cada valor
atomico o nodo.
XQuery permite los nombres de los elementos, atributos y tipos que son
definidos en un esquema a ser utilizados en las consultas. El prolog de una
consulta lista explícitamente los esquemas a ser importados por la consulta,
identificando cada esquema por su namespace objetivo utilizando la
clausula IMPORT:
IMPORT SCHEMA namespace staff = http://dreamhome.com.uk/staff_list.xsd
La siguiente tabla muestra algunos ejemplos de como se pueden referenciar los tipos
importados por el XML Schema así como las funciones que regresan tipos,
parámetros de funciones, y funciones ligadas utilizando la clausula LET que también
puede ser declarada con un tipo de secuencia. Si el tipo de argumento o variable no
XML Query Languages
coincide y no puede ser convertida, se genera un error. Hay varios tipos de
operaciones útiles en tipos:
La función incorporada instance-of() puede utilizarse para probar si un
elemento es de un tipo dado.
La expresión TREAT AS puede utilizarse para asegurar que el valor es de un tipo
especifico durante el análisis estatico de otro modo se genera un error al tiempo
de ejecución.
La expresión TYPESWITCH es similar a la declaración CASE en ciertos lenguajes
de programación, seleccionado una expresión a evaluar basados en el tipo de un
valor de entrada.
La expresión CASTABLE la cual prueba si un valor dado puede ser emitido dentro
de un tipo objetivo dado.
La expresión CAST AS para convertir un valor a un tipo especifico resultado, el
cual debe ser un tipo atómico nombrado, por ejemplo:
IF $x CASTABLE AS xs:string
THEN $x CAST AS xs:string ELSE
XML Query Languages
Tabla Algunos ejemplos de tipos importados por un XML Schema
Secuence Type Declaration Coincide con
element(STAFFNO, STAFFNOTYPE) Un elemento llamado STAFFNO del tipo

STAFFNOTYPE
element(*,STAFFNOTYPE) Cualquier elemento del tipo STAFFNOTYPE
element(STAFF/SALARY) Un elemento llamado SALARY del tipo

xs:decimal (tipo declarado por elementos
SALARY dentro del elemento STAFF)
attribute(@branchNo, BRANCHNOTYPE) Un atributo llamado branchNo del tipo
BRANCHNOTYPE
attribute(STAFF@branchNo) Un atributo llamado branchNo del tipo
BRANCHNOTYPE (el tipo declarado por
branchNo dentro del elemento STAFF)
attribute(@*,BRANCHNOTYPE) Cualquier atributo del tipo
BRANCHNOTYPE)
BASES DE DATOS
AVANZADAS
TEMA
BASES DE DATOS XML
PARTE 2
AGENDA
XML Information Set

XQuery 1.0 y XPath 2.0 Data Model (XDM)
XML y Bases de Datos
Bibliografía
XML Information Set
El XML Information Set (o Infoset) es un extracto

descriptivo de la información disponible de un documento
well-formed XML que cumple con ciertos constraints XML
namespace (W3C, 2001c). El XML Infoset es un intento de
definir un conjunto de términos que otras especificaciones
XML pueden utilizar para referenciar los articulos (items) de
información en un documento XML well-formed (aunque no
necesariamente valido). El Infoset no trata de definir un
conjunto completo de información, ni trata de representar la
mínima información que un procesador XML podría regresar
a una aplicación. Esto tampoco obliga a una interface
especifica o clase de interfaces. Aunque la especificación
presenta la información como un árbol, otro tipo de
interfaces, como basadas en eventos o en consultas, se
pueden utilizar para proporcionar información conformada
en el conjunto de esta.
XML Information Set
Un documento XML Information Set consiste de dos o mas

artículos de información. El articulo de información es una
representación resumen de un componente de un documento
XML tal como un elemento, atributo o instrucción de
procesamiento. Cada articulo de información tiene un conjunto de
propiedades asociadas; por ejemplo, el articulo de información
document tiene propiedades que principalmente pertenecen al el
XML prolog, incluyendo:
[document element], el cual identifica el único elemento del
documento (la raíz de todos los elementos en el documento);
[children], una lista ordenada de artículos de información
conteniendo un elemento, mas un articulo de información por
cada instrucción de procesamiento o comentario que aparece
fuera del elemento del documento; si hay un DTD entonces el
hijo es un DTD information item;
XML Information Set
[unparsed entities], un conjunto desordenado de entidades sin

analizar information items, uno por cada entidades sin analizar
declaradas en el DTD;
[base URI], [character encoding scheme], [version], and
[standalone].
Como mínimo, el conjunto de información debe contener al menos
el document information item y un elemento. Las especificaciones
que hacen referencia a XML Infoset deben ser:
Indicar que information items y propiedades soportan;
especificar como se deben tratar information items y
propiedades no soportadas (por ejemplo, pasarlas sin cambios a
las aplicaciones);
especificar información adicional que se considera significativa
que no este definida en el Infoset;
XML Information Set
designar cualquier salida desde la terminología de

Infoset.
Post-Schema Validation Infoset (PSVI)
El XML Infoset no contiene tipos de información. Para
superar esto, el XML Schema especifica una forma
extendida de el XML Infoset llamada el Post-Schema
Validation Infoset (PSVI). En el PSVI, los
information items representan elementos y atributos
que tienen type annotations y valores normalizados que
son regresados por el procesador XML Schema. El PSVI
contiene toda la información sobre el documento XML
que requiere un procesador de consultas.
XQuery 1.0 and XPath 2.0 Data Model (XDM)
El XQuery 1.0 and XPath 2.0 Data Model (XDM) (el cual
mencionaremos de aquí en adelante solo como “Data
model”) define la información contenida en la entrada XSLT
o procesador XQuery así como todos los valores posibles de
expresiones en los lenguajes XSLT, Xquery y XPath
(W3C,2007h). El modelo de datos esta basado en XML
Infoset, el cual tiene las siguientes características nuevas:
soportado para tipos XML Schema;
representación de colección de documentos y de valores
complejos;
soportado para tipos de valores atómicos;
soportado para secuencias heterogéneas ordenadas.
Se decidió hacer el lenguaje XPath un subconjunto de

XQuery. La especificación de XPath muestra como
representar la información en el XML Infoset como una
estructura de árbol conteniendo siete tipos de nodos
(document, element, attribute, text, comment,
namespace, or processing instruction), con los
operadores XPath definidos en términos de estos siete
nodos. Para retener estas operadores mientras se
utilizan el tipo de sistema mas rico proporcionado por
XML Schema. XQuery extendió el modelo de datos
XPath con información adicional contenida en el PSVI.
El modelo de datos XML Query es una representación de

nodos etiquetados, representados en un árbol, el cual incluye
la notación de identidad de nodo para simplificar la
representación de valores de referencia XML (tales como
valores IDREF, XPointer y URI). Una instancia de este
modelo de datos representa uno o mas documentos
completos o parte de documentos XML, cada uno
representado por su propio árbol de nodos. En el modelo de
datos, cada valor es una secuencia ordenada de cero o mas
items, donde un item puede ser un valor atómico o un nodo.
Un valor atómico como un tipo, cada uno de estos tipos
atómicos definidos en el XML Schema o una restricción de
uno de estos tipos. Cuando un nodo se agrega a la secuencia
para identificar los restos de lo mismo. Por consecuencia un
nodo puede estar en una o mas secuencias y una secuencia
puede contener items duplicados.
El nodo raíz que representa el documento XML es un nodo

del documento y cada elemento en el documento esta
representado por un element node. Los atributos son
representados por attribute nodes y el contenido por text
nodes y element nodes anidados. Los datos primitivos en el
documento son representados por text nodes, formando las
hojas del árbol de nodos. Un element node puede estar
conectado a los attribute nodes y text nodes/ element nodes
anidados. Cada node pertenece a exactamente un árbol y
cada árbol tiene exactamente un nodo raíz. El árbol cuyo
nodo raíz es un document node esta referenciado como un
document y un árbol cuyo nodo raíz es otro tipo de nodo esta
referenciado como fragment
En el modelo de datos, la información sobre los nodos se

obtiene vía funciones de acceso que puede operar en
cualquier nodo. Estas funciones de acceso son análogas a los
artículos de información llamados properties.
Los nodos tienen una unique identity y un document order
este esta definido sobre todos los nodos que están en el
alcance como sigue:
1) El nodo raíz es el primer nodo
2) Cada nodo ocurre antes de todos sus hijos y
descendientes
3) Los nodos namespace siguen inmediatamente el nodo
elemento con los cuales están asociados. El orden relativo
de los nodos namespace es estable pero dependiente de la
implementación.
4) Los nodos atributo siguen inmediatamente a los

nodos namespace del elemento con los que están
asociados. Si ya no hay nodos namespace con un
elemento dado, entonces los nodos atributo
asociados con el elemento que sigue a este. El orden
relativo de los nodos atributo es estable pero
dependiente de la implementación.
5) El orden relativo de los hermanos es el orden en el
cual ocurre la propiedad children de su nodo padre
6) Los hijos y su descendencia ocurren antes de los
siguientes hermanos.
Constraints
El modelo de datos especifica un numero de constraints tales como:
El hijo del nodo documento o elemento debe consistir exclusivamente del
elemento, instrucción de procesamiento, comentario, y nodos texto si no
están vacíos. Atributos, namespace y nodos documento pueden nunca
aparecer como hijos.
La secuencia de nodos en la propiedad children de un documento o nodo
elemento no debe contener dos nodos texto consecutivos.
La propiedad children de un documento o nodo elemento no debe contener
dos nodos texto consecutivos.
La propiedad children de un nodo no debe contener nodos texto vacíos.
Los atributos de un nodo elemento deben tener distintos xs:QNames
(qualifier name)
Los nodos elemento pueden existir sin padres (para representar resultados
parciales durante el procesamiento de la expresión, por ejemplo). Tales nodos
elemento no deben aparecer entre hijos de cualquier otro nodo.
Nodos atributo y nodos namespace pueden existir sin padres. Tales nodos no
deben aparecer sobre los atributos de cualquier nodo elemento.
Como la cantidad de información en formato XML ha

crecido, hay un incremento en la demanda de
almacenamiento, recuperación y consulta de esta
información. Existen dos modelos principales para esto:
modelo centrado en datos y centrado en documentos. En el
modelo centrado en datos se utiliza como el almacenamiento
y formato de intercambio para datos que son estructurados,
aparece en orden regular y mas como lo procesa la maquina
en lugar de que lo entienda el humano. En el modelo
centrado en datos, el hecho de que los datos esta almacenada
y transferida como XML es incidental y otros formatos
pueden también ser utilizados. En este caso, la información
será almacenada en un DBMS relacional u orientado a
objetos. Por ejemplo XML ha sido completamente integrado
dentro de Oracle.
En el modelo centrado en documentos, los documentos están

diseñados para consumo humano (por ejemplo, libros, revistas,
periódicos y correo electrónico). Dada la naturaleza de esta
información, mucha de los datos será irregular e incompleta y su
estructura puede cambiar rápidamente y ser poco predecible.
Desafortunadamente DBMS relacionales u orientados a objetos no
manejan datos de esta naturaleza en particular. Content
Management systems son herramientas importantes para
administrar este tipo de documentos. Subyacente a este sistema
están las native XML database (NXD).
Esta división no abarca todo lo que existe. Datos –
particularmente semi estructurados - pueden almacenarse en una
base de datos nativa XML o en una base de datos tradicional
cuando se requieren pocas características especificas de XML. Por
lo tanto, los limites entre estos dos tipos de sistemas, son cada vez
menos claros, como cada vez mas bases de datos

tradicionales agregan capacidades nativas de XML y
bases de datos nativas XML soportan el almacenamiento
de fragmentos de documentos en bases de datos
tradicionales.
Almacenamiento de XML en Bases de datos
Se han propuesto varios métodos para organizar el
contenido de los documentos XML a fin de facilitar su
posterior consulta y recuperación. Los métodos mas
comunes son los siguientes:
1. Uso de un DBMS para almacenar los documentos como
texto. Es posible utilizar un DBMS de objetos o relacional para
almacenar documentos XML enteros como campos de texto dentro de
los objetos o registros del DBMS. Este método se puede utilizar si el
DBMS tiene un modulo especial para el procesamiento de documentos y
funcionará para almacenar documentos XML sin esquema y centrados
en el documento. Las funciones de indexación el modulo del
procesamiento del documento pueden utilizarse para indexar y acelerar
la búsqueda y recuperación de documentos.
2. Uso de un DBMS para almacenar el contenido del
documento como elementos de datos. Este método funcionaria
para almacenar una colección de documentos que obedecen un esquema
XML especifico o XML DTD. Como todos los documentos tienen
estructura similar, podemos diseñar una base de datos para almacenar
los elementos de datos a nivel de hoja dentro de los documentos XML.
Este método requiere algoritmos de mapeado para diseñar un esquema
de base de datos compatible con la estructura del documento XML tal
como esta especificada en el esquema o DTD XML y para recrear los
Documentos XML a partir de los datos almacenados. Estos

algoritmos se pueden implementar como un modulo DBMS
interno o como middleware independiente que no forma
parte del DBMS.
3. Diseño de un sistema especializado para
almacenar datos XML nativos. Podría diseñarse e
implementarse un nuevo tipo de sistema de bases de datos
basado en el modelo jerárquico (árbol). Dichos sistemas se
denominan DBMS XML nativos. El sistema debería incluir
técnicas de indexación y consulta especializadas y debería
funcionar para todos los tipos de documentos XML. Tambien
podría incluir técnicas de compresión de datos para reducir
el tamaño de los documentos para su mejor almacenamiento.
WebMethods Tamino (EOS v8.2 30-5-15) de Software AG y
Dynamic Application Platform de eXcelon son dos productos

conocidos que ofrecen la funcionalidad DBMS XML nativo.
Creación o publicación de documentos XML
personalizados a partir de bases de datos
relacionales pre-existentes. Como en las bases de datos
relacionales hay cantidades enormes de datos almacenados,
puede darse la necesidad de tener que formatear parte de
estos datos como documentos para intercambiarlos o
visualizarlos en la web. Este método utilizaría una capa de
software middleware separada para llevar a cabo las
conversiones necesarias entre los documentos XML y la base
de datos relacional.
XML y SQL
Se tienen algunos mecanismos para potenciar
completamente a XML. Los estándares SQL:2003 y
SQL:2008 tienen extensiones definidas para que SQL
habilite la publicación de XML, se refiere comúnmente como
SQL/XML (ISO, 2008c). En particular, SQL/XML contiene:
un nuevo tipo de datos nativo XML, el cual proporciona
que los documentos XML sean tratados como valores
relacionales en columnas de tablas, atributos en tipos de
datos definidos por usuarios, variables y parámetros de
funciones;
un conjunto de operadores para este tipo;
un conjunto implícito de mapeos desde datos relacionales
hacia XML.
Ejemplo: Crear una tabla usando el tipo de datos XML
Crear una tabla para almacenar la información de staff como XML

CREATE TABLE XMLStaff(
docNo CHAR(4), docDate DATE, staffData XML,
PRIMARY KEY docNo);
Insertar un renglón en la tabla que acabamos de crear:
INSERT INTO XMLStaff VALUES (‘D001’, DATE”2008-12-01”,XML(‘<STAFF
branchNo = “B005”>
<DOB>1945-10-01</DOB>
<SALARY>30000</SALARY> >/STAFF>’));
Ejemplo: Utilizando operadores XML

1) Liste todo el staff con un salario mayor que £20,000, representado como un
elemento XML contenido el nombre del miembro del staff y numero de sucursal
como un atributo.
SELECT staffno, XMLELEMENT(NAME “STAFF”,fName||’ ’||lName,
XMLATTRIBUTES(branchNo AS “branchNumber”) AS “staffXMLCol”
FROM Staff
WHERE salary >20000;
Donde
XMLELEMENT: operador para generar el valor XML con una solo elemento
XQuery como un hijo de un nodo documento XQuery. El elemento puede tener cero
o mas atributos especificados utilizando la sub clausula XMLATTRIBUTES
XMLELEMENT usa la palabra reservada NAME para nombrar el elemento XML
(STAFF en este caso) y especificar los valores de los datos para aparecer en el
elemento (la concatenación de las columnas fName y lName). Se utiliza el operador
XMLATTRIBUTES para especificar el numero de sucursal como un atributo de este
elemento y da un nombre apropiado utilizando la clausula AS.
Resultado del ejemplo anterior

staffNo staffXMLCol
SL21 <STAFF branchNumber = “B005”>John White</STAFF>
SG5 <STAFF branchNumber = “B003”>Susan Brand</STAFF>
2) Para cada sucursal, liste los nombres de todo el staff cada uno representado como un
elemento XML
SELECT XMLELEMENT(NAME”BRANCH”,
XMLATTRIBUTES(branchNo AS “branchNumber”),
XMLAGG(XMLELEMENT(NAME “STAFF”,fName||’ ‘||lName)
ORDER BY fName ||’ ‘||lName)
) AS “branchXMLCol”
FROM Staff
GROUP BY branchNo;
En este caso, se quiere agrupar la tabla Staff por branchNo y entonces listar el staff
dentro de cada grupo. Se utiliza la función XMLAGG aggregate para hacerlo.
Nótese la utilización de la clausula GROUP BY para listar los elementos
alfabéticamente por nombre de staff. El resultado es el siguiente:
branchXMLCol
<BRANCH branchNumber = “B003”>
<STAFF> Ann Beech</STAFF>
<STAFF> Susan Brand</STAFF>
<STAFF> David Ford</STAFF>
</BRANCH>
<STAFF>Julie Lee </STAFF>
<STAFF> John White</STAFF>
</BRANCH>
<STAFF> Mary Howe</STAFF>
</BRANCH>
Ejemplo utilizando XQuery

Regrese los salarios de staff que son mayores a £20,000
SELECT
XMLQUERY(‘FOR $S IN /STAFF/SALARY WHERE $S>$SAL
AND $S/@branchNo = “B005” RETURN $S”
PASSING BY VALUE ‘15000’ AS $SAL, staffData
RETURNING SEQUENCE BY VALUE
NULL ON EMPTY) AS highSalaries
FROM XMLStaff;
La declaración XQuery donde la clausula WHERE ha sido parametrizada utilizando
la variable $SAL. La clausula PASSING proporciona un valor para $SAL (15000) y
también especifica el articulo contexto staffData. La clausula RETURNING especifica
que la salida será una secuencia XQuery
Bibliografía
Database Systems a Practical Approach to Design,

Implementation, and Management.
Thomas Connolly/Carolyn Begg. Editorial
Pearson/Addison Wesley
Fundamentos de Bases de Datos.
Silbershatz/Korth/Sudarshan. Editorial McGrawHill
Fundamentos de Sistemas de Bases de Datos
Ramez Elmasri, Shamkant B. Navathe
Bases de Datos Distribuidas
Ing. Pablo Salas Castillo

Introducción
Características de las bases de datos
distribuidas
Transacciones distribuidas
Consultas distribuidas
Diseño de una BDD
Fragmentación
Replicación
Protocolos de compromiso (2FC)
Distributed Concurrency control
Una base de datos es un conjunto de datos que se
encuentra en un almacenamiento de
computadora
Típicamente las DB están organizadas en
registros
Un DBMS es un software que administra (gestiona)
los registros de una DB
La tecnología de sistemas de gestión de bases de
datos distribuidas (DDBS) es la unión de lo que
parecería ser dos formas totalmente opuestas de
procesamiento de datos: sistemas de bases de datos y
tecnologías de red. Los sistemas de bases de datos
toman su paradigma del procesamiento de datos en
los cuales cada aplicación definida y mantenida tiene
su propia información. A una en la cual la
información esta definida y administrada
centralmente. Esta nueva orientación resulta en
independencia de datos, donde los programas de
aplicación son inmunes a los cambios
organizacionales fisicos y logicos de la información y
viceversa.
Program 1
Data
Description
File 1
Program 2 Redundant
Data
Data File 2
Description
File 3
Program 3
Data
Description
Figura 1
Program 1 Database
Data Description
Program 2
Data Description
Database
…
Program 3
Figura 2
Uno de las principales motivaciones de la
utilización de DDBS es el deseo de integrar la
información operacional de una empresa y de
proporcionar el acceso centralizado a esto. Por
otro lado la tecnología de redes computacionales
promociona un modo de trabajo que esta en
contra de los esfuerzos de centralización. Al
principio es difícil de entender como estas dos
formas de hacer las cosas tan contrastantes
pueden ser sintetizadas para producir una
tecnología que es mas poderosa y promisoria que
cada una por separado.
La clave de esto es integración no centralización. Es
importante enfatizar que uno de estos términos no
necesariamente implica el otro. Es posible lograr
integración sin necesidad de centralizar y es
exactamente lo que trata de lograr la tecnología de
DDBS.
Los sistemas de computo distribuidos son un numero
de elementos de procesamiento autónomos (no
necesariamente homogéneos) que están
interconectados por medio de una red de computo y
que cooperan para realizar sus tareas asignadas.
El principio fundamental de las bases de datos distribuidas
es: Ante el usuario un sistema distribuido debe lucir
exactamente igual que un sistema que no es distribuido.
El principio fundamental identificado anteriormente nos
conduce a doce reglas complementarias u objetivos:
1. Autonomía local
2. No dependencia de un sitio central.
3. Operación continua.
4. Independencia de ubicación.
5. Independencia de fragmentación.
6. Independencia de replicación.
7. Procesamiento de consultas distribuidas
8. Administración de transacciones distribuidas
9. Independencia de hardware
10. Independencia de sistema operativo
11. Independencia de red
12. Independencia de DBMS
Hay que tomar en cuenta que no todos estos objetivos

son independientes entre sí; tampoco son
necesariamente exhaustivos y tampoco son todos igual
de importantes. Sin embargo los objetivos son utiles
como una base para la comprensión de la tecnología
distribuida y como un marco de trabajo para la
caracterización de la funcionalidad de sistemas
distribuidos específicos.
Podemos definir un DDBS como una colección de
múltiples bases de datos distribuidas lógicamente
interrelacionadas sobre una red. Un DDBMS es
entonces definido como el software que permite
la administración de la DDBS y hace la
distribución transparente a los usuarios.
Una DDBS no solo es una colección de archivos
que se pueden almacenar individualmente, existe
una estructura en estos archivos y el acceso a ellos
deberá ser por una interface en común
En este tipo de bases de datos se nos presentan
situaciones que no tenemos con bases de datos
centralizadas el uso de procesamiento,
almacenamiento y datos compartidos
En las DDBS se tiene transparencia en la
replicación, fragmentación y en la red.
Complejidad
Costo
Distribución del control
Seguridad
Una transacción es una unidad de computación consistente
y confiable. En general es considerada una secuencia de
operaciones de lectura y escritura en la base de datos junto
con los pasos de computación. En este sentido seria un
programa con sentencias SQL incluidas en el mismo.
Flat transactions Tienen un solo punto de inicio
(begin_transaction) y un solo punto de termino
(End_transaction)
Nested transactions Un modelo de transacción
alternativo es el de permitir incluir otras transacciones
con sus propios puntos de inicio y commit. Tales
transacciones son llamadas nested transactions. Estas
están incluidas dentro de otras y son llamadas
usualmente sub transacciones
Begin_transaction Budget.Update
begin
EXEC SQL UPDATE PROJ
SET BUDGET= BUDGET*1.1
WHERE PNAME = “CAD/CAM”
end.
Begin transaction FlightReservation

Begin
Begin_transaction Reservation
begin
input(flight_no, date, customer_name);
EXEC SQL UPDATE FLIGHT
SET STSOLD = STSOLD+1
WHERE FNO = flight_no
AND DATE = date;
EXEC SQL INSERT
INTO FC(FNO, DATE, CNAME,SPECIAL)
VALUES (flight_no, date, customer_name, null);
output(“reservation completed”);
end
Output(“End of Transaction”)
End
Atomicidad Se refiere a que de hecho la transacción es
tratada como una unidad de operación. Por lo tanto,
cada uno de las acciones dentro de la transacción
serán completadas o ninguna de ellas. Esto también
es conocido como propiedad todo o nada.
Consistencia. La consistencia de la
transacción simplemente es que este correcta. En
otras palabras la transacción es un programa correcto
que mapea un estado de base de datos consistente a
otro.
Aislamiento es la propiedad de las transacciones la cual
requiere cada transacción ver a la base de datos
consistente todo el tiempo. En otras palabras una
transacción que se ejecuta no puede revelar su
resultado a otras transacciones en proceso antes de
que se termine satisfactoriamente (commit).
Durabilidad se refiere a la propiedad de las
transacciones la cual asegura que una vez que la
transacción es finalizada satisfactoriamente sus
resultados son permanentes y no pueden eliminarse
de la base de datos.
Query processing layers. Cuando un query es
recibido lo primero que se hace es “dividirlo” en
subqueries basados en la distribución de los datos
entre múltiples sitios. En este paso lo único por lo
que se preocupa es el lugar en donde se encuentra
la información entre los sitios en lugar de el
almacenamiento en varias bases de datos. Entonces
la única información que se requiere es la típica
información del alojamiento de los datos
almacenados en el directorio global. El site que
recibe el query y realiza la división es llamado
control site y es el responsable de que la tarea se
realice de manera satisfactoria
Cada subquery es entonces enviado al site en
donde será procesado . El multi DBMS layer en
cada site “fragmenta” el query para que cada
DBMS lo controle. En esta etapa la información
dentro del directory se utiliza para saber en
donde están los datos. Cada subquery se traduce
dentro del lenguaje de la respectiva DBMS. Se
utiliza información extendida sobre global query
language y lenguajes locales en las DBMS
necesarios para facilitar la traducción. Aun
cuando esta información puede almacenarse en el
directory, es común que se almacene en una base
de datos auxiliar.
Tenemos dos estrategias para diseñar DDBMS
Top-Down Design Process va de un esquema

global a uno especifico. En este proceso
tenemos relaciones distribuidas se dividen en
subrelaciones llamadas “fragmentos”. Este
diseño distribuido consiste de dos pasos:
“fragmentation” y “allocation”. El paso final en
esta estrategia es el diseño físico
Bottom-Up Design Process va de un esquema
especifico al global
Presentación clase2DDBS - top-DownDesignProcess.pptx
Ejemplo de Top Down Design. Sistema de control escolar de la UAEM:
UAEM: Cuenta con escuelas preparatorias, Facultades con licenciaturas y post grados
Dentro de las Facultades tenemos en especifico la Facultad de Ingeniería
Dentro de la FI existen las carreras de I. Mecánica, I. Civil, I.
electrónica, I. En Computación
Específicamente la licenciatura de I. en Computación tiene
las siguientes asignaturas: …
La descomposición de una relación en fragmentos
cada uno tratado como una unidad permite un
numero de transacciones a ejecutar
concurrentemente. En resumen la fragmentación
de relaciones resulta en ejecuciones en paralelo
de un query simple dividido en un conjunto de
subqueries que operan como fragmentos. Esta
fragmentación típicamente incrementa el nivel de
concurrencia y por lo tanto el desempeño del
sistema. Algunas desventajas son si la relación es
mutuamente exclusiva, si tienen mas de un
fragmento pueden sufrir degradación en su
desempeño
Horizontal
Vertical
Parten una relación entre tuplas. Estos fragmentos forman un
subconjunto de tuplas de una relación. Hay dos versiones de
particiones horizontales primaria y derivada. La fragmentación
primaria horizontal de una relación es desarrollada usando
predicados que están definidos en esa relación. Por otro lado
fragmentación derivada horizontal es el particionamiento de la
relación que resulta de los predicados siendo definidos en otra
relación
Requerimientos de información para fragmentación horizontal:
La información incluida en el esquema conceptual global. En
este contexto es importante notar como las relaciones dentro de
la base de datos están conectadas unas con otras, especialmente
joins. En el modelo relacional estas relaciones son representadas
explícitamente.
La fragmentación vertical de una relación R
produce fragmentos R1, R2, …, Rn cada uno de los
cuales contiene un subconjunto de R’s atributos
así como la llave primaria de R. El objetivo de la
fragmentación vertical es el de partir la relación
dentro de un conjunto de relaciones mas
pequeñas tantas como aplicaciones de usuarios
sean ejecutadas en solo un fragmento. En este
contexto una fragmentación “optima” es una que
produce un esquema fragmentado el cual
minimiza el tiempo de ejecución de una
aplicación de usuario que es ejecutada en esos
fragmentos.
EMP ASIG
ENO ENAME TITLE
ENO PNO RESP DUR
E1 J. Doe Elect. Eng
E1 P1 Manager 12
E2 M. Smith Syst. Analyst
E3 A. Lee Mech. Eng. E2 P1 Analyst 24
E4 J. Miller Programmer E2 P2 Analyst 6

E5 B. Casey Syst. Analyst
E3 P3 Consultant 10
E6 L. Chu Elect. Eng
E7 R. Davis Mech. Eng. E3 P4 Engineer 48
E8 J. Jones Syst. Analyst
E4 P2 Programmer 18
Tablas en nuestra Base de datos E5 P2 Manager 24
E6 P4 Manager 48
PROJ PAY
E7 P3 Enginner 36
PNO PNAME Budget LOC Title SAL
E8 P3 Manager 40
P1 Instrumentation 150000 Montreal Elect. Eng 40000
P2 Database Develop. 135000 New York Syst. Analyst 34000
P3 CAD/CAM 250000 New York Mech. Eng. 27000
P4 Maintenance 310000 Paris Programmer 24000

Proj1 Proj2
PNO PNAME BUDGET LOC PNO PNAME BUDGET LOC
P1 Instrumentation 150000 Montreal P3 CAD/CAM 250000 New York
P2 Database Develop. 135000 New York P4 Maintenance 310000 Paris
P1: budget <= 249000

P2: budget > 249000
Pr= { p1, p2}
m1: ( SAL< 30000)

m2: ¬(SAL <=30000) = SAL>30000
PAY1 PAY2
TITLE SAL TITLE SAL
Mech. Eng. 27000 Elect. Eng. 40000
Programmer 24000 Syst. Analyst 34000

Proj1 Proj2
PNO BUDGET PNO PNAME LOC
P1 150000 P1 Instrumentation Montreal
P2 135000 P2 Database Develop. New York
P3 CAD/CAM New York
P4 Maintenance Paris
Replication and replica control protocols
Como ya lo habíamos mencionado tener replicas incrementa
la disponibilidad de la información si se hace correctamente
se eliminan los SPF (single point of failure)
Strict Replica Control Protocol son los que obligan tener
una copia equivalente en cada nodo. El protocolo ROWA
(Read One Write All) es el que convierte una lectura lógica a
una lectura en cualquiera de sus replicas y convierte una
escritura lógica a una escritura en todas sus replicas. Esto se
realiza cuando la transacción de update realiza el commit,
todas las replicas tienen el mismo valor.
Cuando alguna de las replicas no esta disponible, la
transacción no se puede terminar. Entonces ROWA falla en
cumplir con un objetivo fundamental de la replicación la de
proporcionar alta disponibilidad. una variación de ROWA es
ROWA-A (Read One Write All Available). La idea general es
que los comandos de escritura se ejecutan en las copias
disponibles y la transacción termina. Las copias que no están
disponibles tienen que actualizarse en cuanto lo estén.
Lazy Replica Control Protocol no permiten realizar
las operaciones de escritura en todas las copias del
data item dentro del contexto de la transacción que
actualiza al data item. En lugar de esto, realizan la
actualización de una o mas copias y después
propagan los cambios en todas las copias. Un
esquema de replicación lazy puede caracterizarse
usando cuatro parámetros básicos: El parámetro
ownership define los permisos para actualizar las
copias en la replica. Si la replica es actualizable se
llama primary copy, en otro caso es llamada
secondary copy.
El nodo que almacena la primary copy de un objeto es
llamada master para este objeto mientras que los nodos
que almacenan las copias secundarias son llamados
slaves. El parámetro propagation define cuando las
actualizaciones a una replica deben realizarse hacia los
nodos que almacenan otras replicas del mismo objeto. El
parámetro refreshment define la calendarización de las
transacciones de refresh. Si una transacción refresh es
ejecutada tan pronto como se recibe por algún nodo, la
estrategia se realizará de manera inmediata
(immediate). La yuxtaposición de los parámetros de
propagation y refreshment determinan una estrategia
de propagación de actualización . Por ejemplo una
estrategia de propagación de actualización deferred-
immediate tiene una propagación aplazada (deferred
propagation) y un refreshment immediate.
El parámetro de configuration caracteriza a los
nodos y a las redes.
Basado en esta caracterización, los protocolos de
replicación lazy se pueden clasificar en dos grupos.
El primer grupo consiste en métodos de replicación
lazy donde todas las copias de las replicas son
actualizables (update anywhere). En este caso hay
un group ownership en las replicas. La estrategia
común de propagación implementado para este
esquema es deferred-immediate. Un conflicto
aparece si dos o mas nodos actualizan el mismo
objeto en la replica. Hay varias políticas de
detección y resolución de conflictos que pueden ser
basados en ordenamiento “timestamp”, prioridad
de los nodos, entre otros.
El problema con la resolución de conflictos es que durante cierto
periodo de tiempo la base de datos puede estar en estado
inconsistente. Los conflictos no pueden evitarse pero su detección
puede minimizarse por medio de una immediate propagation.
La segunda clase consiste en los protocolos donde hay un solo
master que es el que se actualiza (llamado lazy master method).
Hay varias estrategias de refreshment para este esquema de
replicación. Con un on-demand refreshment, cada vez un query se
manda ejecutar. Copias secundarias que son leídas por el query
son refrescadas cuando se recibe el refresh de todas las
transacciones. Por lo tanto un atraso puede introducirse en los
tiempos de respuesta del query. Cuando se utiliza un group
refresh las transacciones de refresh se ejecutan en grupos de
acuerdo con los requerimientos de la aplicación. Con un periodic
approach el refreshment es calendarizado en intervalos fijos.
Todos los tiempos de refreshment y las transacciones de refresh
son ejecutadas. Finalmente con la periodic propagation los
cambios son realizados por las transacciones de actualización y
son almacenados en el master y propagados periódicamente.
Nótese que se utiliza la immediate propagation con todas las
estrategias de refreshment.
Full replication Partial Partitioning
replication
Query Easy Same difficulty

processing
Directory Easy or Same difficulty

management nonexistent
Control Moderate Difficult Easy

concurrency
Realiability Very high High Low

reality Possible Realistic Possible
application application
Two Phases Commit Protocol (2PC)
El protocolo 2PC es un protocolo que asegura el
commitment atómico de transacciones
distribuidas. Este extiende los efectos de las
acciones del commit local a transacciones
distribuidas insistiendo que todos los sitios
involucrados en la ejecución de las transacciones
distribuidas estén de acuerdo de confirmar la
transacción antes de tener efectos permanentes.
Hay un número de razones por lo que la
sincronización en los sitios es necesaria.
Primero dependiendo del algoritmo de control de
concurrencia que se utilice algunos schedulers
podrán no estar listos para terminar la
transacción.
Otra posible razón de que un participante no este
de acuerdo en realizar el commit es si se presenta
un deadlock que requiere que este participante
aborte la transacción. Esta capacidad es
importante y es llamada unilateral abort.
Una descripción de un protocolo 2PC que no considera
fallas es como sigue: Inicialmente, el coordinador
escribe un registro begin_commit en su registro,
manda un mensaje de “prepare” a todos los
participantes en el site y entran a estado WAIT.
Cuando el participante recibe el mensaje “prepare”
revisa si se puede realizar el commit de la transacción.
Si es así, el participante escribe un registro “READY”
en el log y envía su mensaje de “vote-commit” al
coordinador y entra en estado READY; en otro caso el
participante escribe un mensaje de abort en el log y
envía un mensaje de “vote-abort” al coordinador.
Si la decisión en el site es abort, esta se
realiza (unilateral abort). Después de que
el coordinador recibe una replica de cada
participante se decide el commit o abort. Si
solo un participante tiene un voto
negativo, el coordinador tiene que abortar
la transacción globalmente. Así que se
escribe un abort record y se envía un
mensaje de “global-abort” a todos los
participantes y entra en estado ABORT.
De otro modo se escribe el registro y se envía un
mensaje “global-commit” a todos los
participantes y entra en estado COMMIT. Los
participantes abortaran o aceptaran la
transacción de acuerdo a las instrucciones del
coordinador y enviarán un mensaje de
reconocimiento, en este punto el coordinador
termina la transacción escribiendo un registro
de end_of_transaction en el log.
Bases de Datos Distribuidas
Ing. Pablo Salas Castillo

En condiciones normales, todos los mecanismos de control
de concurrencia deben asegurar que la consistencia de los
objetos sea preservada y cada acción atómica sea
completada en un tiempo finito. En resumen, un buen
mecanismo de control de concurrencia para DDBMS serán:
- Ser tolerante a fallas de comunicación y site
- Permitir paralelismo para satisfacer los
requerimientos de desempeño
- Incluir poco overhead computacional y de
almacenamiento
- Realizar tareas satisfactoriamente en un medio
ambiente de redes con un retraso significativo de
comunicaciones.
- Colocar pocas restricciones en la estructura de las
acciones atómicas
Un problema que se tiene en la DDBMS es multiple-copy
consistency problem que ocurre cuando un objeto es replicado
en diferentes localidades. Claramente para mantener la
consistencia de la base de datos global, cuando un objeto es
replicado a un site deberá actualizarse en todas las otras copias.
Si no es así la base de datos esta inconsistente.
Distributed Serializability
Si el schedule de una transacción en ejecución en cada site es
serializable, entonces el global schedule (la unión de todos los
schedules locales) es también serializable permitiendo que los
ordenamientos locales sean idénticos. Esto requiere que todas
las sub transacciones aparezcan en el mismo orden en schedules
equivalentes idénticos para todos los sites. Esto si la
subtransacción de Tj en el site S1 es denotado T1 i , se debe
asegurar que si T1 i < T1j entonces:
T1 i < T1j Para todos los sites Sx, en el cual Ti y Tj tienen
subtransacciones
La solución al control de concurrencia en un medio
ambiente distribuido esta basado en dos enfoques
principales: locking y timestamping. Asi que con
transacciones ejecutadas concurrentemente tenemos:
- Locking garantiza que la ejecución concurrente es
equivalente a algunas ejecuciones seriales de estas
transacciones
- -Timestamping garantiza que la ejecución
concurrente es equivalente a una ejecución serial
especifica de estas transacciones, correspondiendo al
orden del timestamping
Schedule: Una secuencia de operaciones para un
conjunto de transacciones concurrentes que conservan
el orden en cada transacción individual.
Una transacción comprende una secuencia de
operaciones consistentes de acciones de lectura y
escritura, seguidas por una acción de commit o abort.
Un schedule S consiste en una secuencia de
operaciones de un conjunto de transacciones T1, T2, …,
Tn sujetas a la restricción que el orden de las
operaciones para cada transacción es respetado en el
schedule. Asi, para cada transacción T, en el schedule
S, el orden de las operaciones en T debe ser el mismo
en el schedule S.
Serial Schedule: Es un schedule donde las operaciones
de cada transacción son ejecutadas consecutivamente
sin ninguna intercalación de operaciones de otras
transacciones.
En un serial schedule, las transacciones son realizadas
en orden. Por ejemplo si tenemos dos transacciones T1
y T2 el serial order será T1 seguido de T2 o T2 seguido
de T1, esto en ejecución serial no hay una interferencia
entre transacciones porque solo una es ejecutada en un
tiempo dado. Sin embargo, no hay garantía que los
resultados de todas las ejecuciones en serie de un
conjunto dado de transacciones sean idénticas. En un
banco por ejemplo, esto afecta cuando el interés es
calculado en una cuenta antes o después de que se
realice un gran deposito.
NonSerial Schedule: Es un schedule donde las
operaciones de un conjunto de transacciones son
ejecutadas intercaladas.
Si el conjunto de transacciones concurrentes, podemos
decir que un nonserial schedule es correcto si produce
el mismo resultado como alguna ejecución serial. Tal
schedule se le llama serializable. Para prevenir
inconsistencias de transacciones interfiriendo unas con
otras; es esencial garantizar la serialibilizacion de
transacciones concurrentes.
Si también cambiamos el orden de las siguientes
operaciones que no tienen conflictos se producirá el serial
schedule S3 equivalente mostrado en la figura 3
- Cambie el orden del write(balx) de T8 con
write(baly) de T7
- Cambie el orden de read(balx) de T8 con
read(baly) de T7
- Cambie el orden de read(balx) de T8 con el
write(baly) de T7
Schedule S3 es un serial schedule y puesto que S1 y S2 son
equivalentes a S3, S1 y S2 son serializable schedules.
Este tipo de serializability es llamado conflict serliazability.
Un conflict serializable schedule ordena cualquier
operación en conflicto en la misma forma de la ejecución
serial.
Revisar diagrama de transacciones en la hoja de Excel
Los protocolos de bloqueo de 2 fases (two-phase
locking 2PL) se utilizan para asegurar serializability
para DDBMS, existen varios tipos: centralized 2PL,
primary copy 2PL, distributed 2PL y majority
locking.
Centralized 2PL: Con este protocolo hay un solo site que
mantiene toda la información del bloqueo. Solo hay un
solo scheduler, o lock manager para todo el DDBMS que
puede activar o liberar locks. El protocolo centralized 2PL
para una transacción global inicia en el site S1 y funciona
de la siguiente manera:
(1) El coordinador de transacciones del site S1 divide la
transacción en un numero de sub transacciones utilizando la
información del global system catalog. El coordinador es el
responsable de que se conserve la consistencia.
Si la transacción involucra una actualización del data item
que es replicado, el coordinador debe asegurar que todas las
copias del data item se actualicen. Así que el coordinador
requiere de locks exclusivos en todas las copias antes de
actualizarlas y liberar estos locks. El coordinador puede
elegir el utilizar cualquier copia del data item para leer;
generalmente la copia del site local si es que existiera.
(2) Los administradores de transacciones locales incluidos en
la transacción global piden y liberan locks del centralized
lock manager usando las reglas normales para el 2PL.
(3) El centralized lock manager revisa que el requerimiento
de un lock para un data item este disponible. Si es asi el lock
manager envía un mensaje de regreso al sitio original
informando que el lock ha sido asignado. En otro caso coloca
el requerimiento en la cola hasta que se logra obtener el lock.
Una variación de este esquema es para el coordinador de
transacciones al hacer todas las peticiones de locks en lugar
del local transaction manager. En este caso el lock manager
interactúa solo con el lock coordinator y no con los local
transaction managers individuales.
La ventaja de el centralized 2PL es que la implementación es
relativamente directa. La detección de deadlocks no es mas
difícil que en los DBMS centralizados, porque un solo lock
manager mantiene toda la información de los locks. La
desventaja son cuellos de botella y la poca confiabilidad pues
en el caso de falla del site en donde esta el lock manager
causaría una falla mayor en el sistema.
Primary Copy 2PL: Este protocolo intenta resolver las
desventajas del centralized 2PL por medio de la distribución de
los lock managers a un numero de sitios. Cada lock manager es
entonces responsable de administrar los locks en un conjunto de
data items. Para cada data item replicado una copia es elegida
como primary copy, las otras copias son llamadas slave copies.
La elección de cual de los sites se eligen como primary site es
flexible y el site que es elegido para administrar los locks para
primary copy NO debe tener la primary copy de ese data item.
Este protocolo es una extensión directa del centralized 2PL. La
diferencia principal es que cuando un item es actualizado, el
coordinador de transacciones debe determinar el orden en el cual
la primary copy se realizará para enviar los requerimientos de
locks al lock manager apropiado. Aquí solo es necesario el lock
exclusivo para la primary copy. Una vez que se actualiza el cambio
puede ser propagado a los slave copies. Esta acción debe realizarse
lo antes posible para prevenir que otras transacciones lean valores
desactualizados. Sin embargo no es estrictamente necesario el
hacer las actualizaciones como una operación atómica.
Este protocolo solo garantiza que la primary copy este
siempre actualizada.
Este enfoque puede utilizarse cuando se replica solo
información selectiva, cuando las actualizaciones son pocas o
sitios que no necesitan tener siempre la ultima versión de la
información. Las desventajas de este protocolo son la
administración del deadlock se hace mas compleja pues
administra varios lock managers y hay todavia un grado de
centralización en el sistema, los requerimientos de locks para
una primary copy en especifico puede ser manejada
solamente por un site. Esta desventaja puede ser
parcialmente cubierta nominando sites de respaldo para
tener la información de los locks. Este enfoque tiene un costo
de comunicación bajo y mejor desempeño que el centralized
2PL, puesto que se tiene menor bloqueo remoto.
Distributed 2PL: Este protocolo también intenta resolver
las desventajas del centralized 2PL por medio de la
distribución de los lock managers en cada site. Cada lock
manager es entonces responsable de administrar los locks
de su información en su site. Si la información no esta
replicada, este protocolo es equivalente al primary copy
2PL. En otro caso distributed 2PL implementa el (ROWA)
replica control protocol. Esto significa que cualquier copia
de un objeto replicado puede utilizarse para operación de
lectura. Pero todas las copias deberán tener un lock
exclusivo antes de actualizar el item. Este esquema trata
con locks de manera descentralizada evitando el
inconveniente del control centralizado. Sin embargo las
desventajas de este enfoque son el manejo de deadlocks es
mas complejo tratando con multiples lock managers y los
costos de comunicación son mayores que el primary copy
2PL, pues todos los objetos deben estar bloqueados antes
de actualizarse.
Majority locking: Este protocolo es una extensión del distributed
2PL para evitar la necesidad del bloqueo de todas las copias de
un item replicado antes de la actualización. Otra vez, el sistema
mantiene a un lock manager por cada site a administrar los
bloqueos de todos los datos en el site. Cuando la transacción
desea leer o escribir data items que se están replicando en n
sites, se debe enviar un requerimiento de lock en mas de la
mitad de los sites en donde esta almacenado el data item. La
transacción no puede proceder hasta que obtenga un lock en la
mayoría de las copias. Si la transacción no recibe una mayoría
en un cierto periodo de tiempo, el requerimiento se cancela e
informa a todos los sites de la cancelación. Si recibe la mayoría,
informa a todos los sites que tiene el lock. Cualquier numero de
transacciones pueden tener simultáneamente un lock
compartido en la mayoría de las copias.
Este esquema también evita el inconveniente del control
centralizado. Las desventajas son que el protocolo es mas
complicado, la detección de deadlocks es mas complejo y el
bloqueo requiere al menos de [(n+1)/2] mensajes para cada
requerimiento de lock y [(n+1)/2] locks compartidos
Timestamp protocol: El objetivo del timestamping es el de
ordenar las transacciones globalmente de tal forma que las
mas viejas (transacciones con menor timestamp) tienen
prioridad en un evento de conflicto. En el medio ambiente
distribuido, todavía se tiene que generar un único
timestamp local y globalmente. Claramente se puede
utilizar el reloj del sistema o un contador incremental en
cada site. Los relojes en diferentes sites no deben estar
sincronizados, similarmente el contador incremental, pues
existe la posibilidad de generar el mismo valor para este.
Se puede utilizar la concatenación del local timestamp con
el identificador del site para evitar esta situación <local
timestamp, site id>. El identificador del site será colocado en
la posición menos significativa para asegurar que los
eventos pueden ser ordenados de acuerdo con su ocurrencia.
Utilizar la base de datos de prueba (QuickStart) de
NuoDB para realizar los siguientes ejercicios:
Conectar otra pc (pc1 y pc2) a ese domain
Crear la tabla prueba (id, nombre, direccion) en la pc1
Insertar los registros de la tabla players en prueba.
Apagar pc1 falla abrupta de servidor (botonazo). Revisar
si se tiene acceso a la tabla prueba desde la pc2.
Iniciar la pc1
Revisar si las 2 pcs tienen acceso a la tabla de prueba
Eliminar tabla prueba desde pc2 (drop)
Comentarios y conclusiones
Principles of distributed database systems / by
M. Tamer Ózsu, Patrick Valduriez.
Database Systems a Practical Approach to
Design, Implementation, and Management.
arquitectura de un Datawarehouse
Las empresas han comenzado a aprovecharlos cada vez mas numerosos
datos en línea para tomar mejores decisiones sobre sus actividades por
ejemplo los artículos que deben tener en inventario y el modo de dirigirse
mejor a los clientes para aumentar las ventas. Muchas de las consultas sin
embargo son bastantes complejas y algunos tipos de información no
pueden extraerse ni siquiera empleando SQL.
Se encuentran disponibles varias técnicas y herramientas de ayuda a la
toma de decisiones.
Existen herramientas para el análisis de datos que permiten ver los datos
de diferentes formas otras herramientas de análisis realizan un calculo
previo de resúmenes de cantidades muy grandes de datos con objeto de
dar respuestas rápidas a las consultas.
El almacenamiento y recuperación de los datos para la ayuda en la toma
de decisiones plantea varios problemas:
• Aunque muchas consultas para la toma de decisiones pueden
escribirse en SQL, otras no pueden expresarse o no pueden hacerlo
con facilidad. En consecuencia se han propuesto varias extensiones
de SQL para facilitar el análisis de datos OLAP (Online Analytical
Processing) que son las herramientas y técnicas para el análisis de
datos que pueden dar respuestas casi instantaneas a las consultas de
datos resumidos, aun cuando la base de datos sea extremadamente
grande.
• Los lenguajes de consulta de DB no son eficaces para el análisis
estadístico detallado de datos. Existen paquetes que ayudan en el
análisis estadístico los cuales tienen interfaces con las DB para
permitir que se almacenen en ellas y recuperar de manera eficiente
esta información.
• Las grandes empresas tienen varios orígenes de datos que necesitan
utilizar para adoptar decisiones empresariales. Los orígenes pueden
almacenar los datos según diferentes esquemas. Por motivos de
rendimiento (y control de la organización) los orígenes de datos no
suelen permitir que otras partes de la empresa recuperen datos a
petición.
Para ejecutar de manera eficiente las consultas sobre los datos tan
diferentes las empresas han creado almacenes de datos. Estos reúnen
los datos de varios orígenes bajo un esquema unificado en un solo
sitio. Por lo tanto ofrecen al usuario una sola interfaz uniforme para
los datos.
• Las técnicas de descubrimiento de conocimiento intentan determinar
de manera automática reglas estadísticas y patrones a partir de datos.
El data warehouse combina técnicas de descubrimiento creadas por
los investigadores de la inteligencia artificial y los analistas estadísticos
con las técnicas de implementación eficiente que permiten utilizarlas
en bases de datos extremadamente grandes.
• Un data warehouse puede definirse como una colección orientada a
sujetos (subject oriented collection) de datos integrados desde varias
DB operacionales. La información es clasificada por temas de interés
para los analistas de negocios, tales como clientes, productos y
cuentas. Un data warehouse puede ser directamente accesado por
los usuarios finales con poderosas estaciones de trabajo a través de
sofisticadas herramientas de análisis, eliminando la necesidad de
tener un conjunto de programadores de aplicaciones con amplio
conocimiento del mismo.
• La información en el warehouse es de naturaleza histórica, reflejando
transacciones OLTP que han ocurrido en los meses o años anteriores.
Esto facilita el acceso y el análisis pues la información típicamente es resumida
y agregada en una forma multi dimensional.
OLAP
Considérese una aplicación en que una tienda desea averiguar las prendas que son
mas populares. Supóngase que las prendas están caracterizadas por nombre de
articulo, color y talla y que se tiene la relación ventas con el esquema
ventas(nom_art, color, talla, num)
all color
Talla:
Oscuro pastel blanco Total
Falda 8 35 10 53
Vestido 20 10 5 35
nom_art Camisa 14 7 28 49
Pantalón 20 2 5 27
Total 62 54 48 164
Tabulación cruzada de ventas

Dada una relación utilizada para el análisis de datos se pueden identificar algunos de sus
atributos como atributos de medida, por ejemplo numero que mide los artículos vendidos.
Todos los demás atributos en la relación se identifican como atributos de dimensión ya que
definen las dimensiones en las que se ven los atributos de medida.
Los datos que pueden modelarse como atributos de dimensión y medida se denominan datos
multidimensionales.
La siguiente tabla es un ejemplo de tabulación cruzada, también denominada tabla dinámica.
En general las tabulaciones cruzadas son tablas en las que los valores de uno de los atributos
forman el encabezado de los renglones, los valores del otro atributo forman el encabezado de
las columnas
2 5 3 1 11
4 7 6 12 29
2 8 5 7 22
8 20 14 16
Oscuro 20 62
4
34
35 10 54
color
7 2 18
Pastel 9
21
45
Blanco 10 8 28 5 48 42 pequeña
77 mediana
grande talla
all 53 35 49 27 164
falda Vestido camisa all all
Nom_articulo
Nom_articulo color talla Numero
Falda oscuro all 8
Falda pastel all 35
Falda blanco all 10
falda all all 53
vestido oscuro all 20
vestido pastel all 10
vestido blanco all 5
vestido pastel all 35
camisa blanco all 14
camisa all all 7
pantalón oscuro all 28
pantalón pastel all 49
pantalón blanco all 20
En la siguiente figura se muestra la arquitectura simplificada del data warehouse.
Una o mas bases de datos origen, conteniendo información operacional actualizada por
aplicaciones OLTP integradas en una base de datos destino, o data warehouse.
La base de datos destino es accesada a través de queries por aplicaciones de escritorio
tales como herramientas de análisis y consultas, reporteo y data mining. Aplicaciones
de escritorio populares para análisis de datos son hojas de calculo.
El repositorio de metadatos que mantiene la huella de toda la información actualmente
almacenada en el data warehouse. Metadata típica incluye descripciones de tablas
Destino con sus definiciones del origen. El repositorio de metadata es útil para aislar
El data warehouse de cambios en el esquema de las bases de datos fuente, por consiguiente,
cuando ocurre un cambio en el esquema origen de la DB, el administrador del DWH puede
simplemente actualizar el repositorio y el cambio automáticamente es propagado a la DB
destino y a las aplicaciones OLAP.
La integración de múltiples DB fuente en el DWH provoca diferentes situaciones:
El tiempo de diseño, un esquema integrado debe definirse. Integración del esquema en el
DWH es similar a la integración del esquema en sistemas múltiples de DB y debe lidiar con
conflictos de semántica a través de distintos DB fuentes autónomas. La integración del
Esquema en data warehousing típicamente asume que cada DB fuente proporciona una
Interface relacional. Esta integración del esquema puede ser hecha definiendo vistas
Relacionales sobre las tablas fuente.
Cargar el DWH depende de la extracción de la información y utilerías de limpieza y carga.
La extracción de información se implementa utilizando gateways que soportan interfaces
estándar.
tales como ODBC (Open Database Conectivity). Los datos usualmente son limpiados para
reducir inconsistencias, como entradas omitidas o valores inválidos. Después de la
extracción y limpieza la información es cargada en el DWH con procesos adicionales tales
como sumarización o agregación (aggregation). El cargado de la información esencialmente
significa materializar las vistas relacionales del esquema integrado. Por lo tanto la información
en el DWH esta organizada para un procesamiento de consultas eficiente con varios tipos de
índices.
Después de que fue cargado, el DWH debe ser refrescado de vez en vez para reflejar las
actualizaciones de las fuentes. El refreshing es usualmente hecho periódicamente, por
ejemplo diariamente o cada semana. Esto puede ser realizado inmediatamente después de
cada actualización de las aplicaciones OLAP que necesitan ver los datos actuales. Para evitar
cargar tablas enteras, solo actualizaciones de los datos fuente podría propagarse en el DWH.
Esto se realiza usando técnicas de replicación asíncronas que realizan mantenimientos
incrementales de replicas desde copias primarias. OLTP
OLAP
Metadata
Query/Analysi Repository
s Reporting Queries Integrate
Data Mining Target

DB Source
DBs
Figura 1. Arquitectura de Data Warehouse

Hay muchas formas de construir un DWH en la organización. Dos enfoques extremos son
centralizado y descentralizado. Pero pueden combinar varias formas.
OLAP Queries
Datamart
Central
Data
Warehouse
OLAP Queries
Datamart
Figura 2. Centralized Data Warehouse

El enfoque centralizado esta ilustrado en la figura 2 de la pagina anterior. Esta carga todas las
DB operacionales de la organización dentro de una DWH central. Grupos funcionales, tales
como departamentos, pueden entonces extraer un subconjunto de información y cargarlos
en data warehouses funcionales mas pequeños llamados data marts. La ventaja de este
enfoque es que asegura la consistencia de la información para la toma de decisiones
a través de la organización. Sin embargo, es difícil crear un modelo global empresarial para
el DWH central y asegurarse que todos los grupos funcionales lo utilicen.
El enfoque descentralizado esta ilustrado en la figura 3. El DWH aquí es virtual y proporciona
a las aplicaciones OLAP con una vista global de la información. usando un diccionario de
datos global administrado por el gateway del DWH. Los queries globales se descomponen
dentro de queries locales enviados a las DBMS operacionales y los resultados son
integrados por el gateway del DWH. Esta es una aplicación directa de la tecnología de
Bases de datos distribuidas (DDBS).
Global View
OLAP Data
Queries Warehouse
Global DWH
Data
Gateway Warehouse
Figura 3. Decentralized Data Warehouse

Operational Data Store
Un Operational Data Store (ODS) es un repositorio de información operacional actual e
integrada utilizada para análisis. Esta frecuentemente estructurada y proporcionada con
información del mismo modo que el DWH, pero puede de hecho actuar simplemente
como un área temporal para información a ser movida dentro del DWH.
ODS es creada frecuentemente cuando sistemas operacionales legacy están incluidos y
son incapaces de lograr los requerimientos de reporteo. Lo ODS proporcionan a los
usuarios la facilidad de utilizar bases de datos relacionales mientras permanecen
distantes de las funciones de toma de decisiones de los DWH.
ETL Manager
El ETL Manager realiza todas las operaciones asociadas al ETL (Extraction,
Transformation and Loading) de los datos dentro del DWH. La información será extraída
directamente desde la fuente o mas comúnmente del ODS.
Warehouse Manager
Realiza todas las operaciones asociadas con la administración de la información en el
DWH. Estas operaciones incluyen:
• Análisis de información para asegurar consistencia
• transformación y fusión de la información desde el almacenamiento temporal a las
tablas del DWH.
• Creación de índices y vistas de las tablas
• generación de des normalización (en caso de ser necesario)
• Generación de aggregations
• Respaldo y archivado de información
En algunos casos el warehouse manager también genera query profiles para determinar
que índices y aggregations son apropiados. Un query profile puede generarse para cada
usuario, grupo de usuarios o el DWH y esta basado en la información que describe las
características de los queries tales como su frecuencia, tablas que consulta y tamaño del
resultado obtenido.
Query Manager
Realiza todas las operaciones asociadas con la administración de los queries de los
usuarios. La complejidad del query manager esta determinada por la infraestructura
proporcionada por las herramientas de acceso de usuarios finales y la base de datos. Las
operaciones realizadas por este componente incluyen direccionamiento de queries a las
tablas apropiadas y calendarizan la ejecución de estos. En algunos casos, el query
manager también genera query profiles para ayudar al warehouse manager a
determinar que índices y aggregations son apropiados.
Detailed Data
Es un área del warehouse que almacena toda la información detallada en el esquema de
la DB. en la mayoría de los casos, detailed data no esta almacenada en línea pero esta
disponible por medio de agregar información al siguiente nivel de detalle. Sin embargo,
en bases regulares, detailed data es agregada al DWH para complementar información
adicional.
Lightly and Highly Summarized Data
Esta área del DWH almacena toda la información predefinida resumida generada por el
warehouse manager. Esta área del warehouse es transitoria, esto será sujeto a cambio
en el transcurso de la operación a razón de responder los cambios a los query profiles.
Archive/Backup Data
Esta área del warehouse almacena información detallada y resumida para propósitos de
archivado y respaldo. Aun cuando la información resumen es generada a partir de la
información detallada, esto puede ser necesario para respaldos en línea de información
resumida si esta información es mantenida mas allá de su periodo de retención por la
información detallada.
Metadata
Esta área del DWH almacena toda las definiciones de metadata (la definición de la
información) utilizada por todos los procesos en el DWH. La metadata es utilizada para:
• Procesos de extracción y carga – metadata es utilizada para “mapear” recursos de
datos en una vista en común de la información dentro del DWH.
• El warehouse management process – metadata se utiliza para automatizar la
producción de tablas sumarizadas.
• Como parte del query management process –metadata se utiliza para direccionar un
query a su fuente de datos asociada correcta.
La estructura de metadata difiere entre cada proceso, puesto que el propósito es
diferente. Esto significa que múltiples copias de metadata describen el mismo data item
contenido en el DWH. En resumen, la mayoría de las herramientas para administración
de copias y acceso a usuarios finales utiliza estas versiones de metadata.
Específicamente herramientas de administración de copias utilizan metadata para
entender el mapeo de las reglas para aplicar a razón de convertir los datos fuente dentro
de una forma común. Las herramientas de acceso para usuarios finales utilizan metadata
para entender como construir un query. La administración de metadata dentro del DWH
es una tarea complicada que no debe ser sobre estimada.
Herramientas para usuarios finales
El propósito principal de un DWH es el de ayudar a los tomadores de decisiones. Estos
usuarios interactúan con el DWH utilizando herramientas de acceso para usuarios
finales. El DWH deberá soportar eficientemente análisis personalizado y rutinario. Se
logra un alto desempeño realizando pre-planeación de los requerimientos para joins,
summations y reportes periódicos para usuarios finales.
Aunque las definiciones de herramientas de acceso a usuarios finales pueden diferir las
podemos catalogar en cuatro grupos principales:
• Herramientas de reporteo y consulta
Incluyen herramientas production reporting tools y report writers. Production reporting
tools son utilizadas para generar reportes operacionales regulares o soportan alto
volumen de batch jobs, tales como ordenes de clientes / facturas y pago a empleados.
Report writers por el otro lado, son herramientas de escritorio sin costo diseñadas para
usuarios finales.
• Herramientas de desarrollo de aplicaciones
• Herramientas OLAP
• herramientas data mining
Herramientas para consultas tenemos al Query By Example (QBE)
• Herramientas de desarrollo de aplicaciones
Estas herramientas pueden accesar a la mayoría de las bases de datos comerciales como
Oracle, Sybase, DB2 e Informix.
• Herramientas OLAP
Están basadas en el concepto de DBs multidimensionales y proporcionan a usuarios
avanzados analizar la utilización compleja de información, vistas multidimensionales.
Aplicaciones típicas de negocios para estas herramientas incluyen medir la efectividad
de una campaña de marketing, proyección de venta de productos y análisis de
capacidades. Estas herramientas asumen que la información esta organizada en un
modelo multidimensional soportado por una base de datos multidimensional especial
(MDDB) o por una base de datos relacional diseñada para habilitar consultas
multidimensionales.
• herramientas data mining
Data mining es el proceso de descubrimiento del significado de nuevas correlaciones,
patrones y tendencias por medio de la extracción de grandes cantidades de información
utilizando técnicas estadísticas, matemáticas y de inteligencia artificial. Data mining
tiene el potencial de reemplazar las capacidades de herramientas OLAP, como su
característica principal, el data mining es capaz de construir modelos predictivos en
lugar de retrospectivos.
ETL en Oracle:
https://docs.oracle.com/cd/B19306_01/server.102/b14223/ettover.htm
https://docs.oracle.com/cd/B19306_01/server.102/b14223/extract.htm
Physical Extraction Methods
Depending on the chosen logical extraction method and the capabilities and
restrictions on the source side, the extracted data can be physically extracted by two
mechanisms. The data can either be extracted online from the source system or
from an offline structure. Such an offline structure might already exist or it might be
generated by an extraction routine.
There are the following methods of physical extraction:
• Online Extraction
• Offline Extraction
Online Extraction
The data is extracted directly from the source system itself. The extraction process can
connect directly to the source system to access the source tables themselves or to an
intermediate system that stores the data in a preconfigured manner (for example, snapshot
logs or change tables). Note that the intermediate system is not necessarily physically
different from the source system.
With online extractions, you need to consider whether the distributed transactions are
using original source objects or prepared source objects.
Offline Extraction
The data is not extracted directly from the source system but is staged explicitly outside the
original source system. The data already has an existing structure (for example, redo logs,
archive logs or transportable tablespaces) or was created by an extraction routine.
You should consider the following structures:
• Flat files
Data in a defined, generic format. Additional information about the source object is
necessary for further processing.
• Dump files
Oracle-specific format. Information about the containing objects may or may not be included,
depending on the chosen utility.
• Redo and archive logs
• nformation is in a special, additional dump file.
• Transportable tablespaces
A powerful way to extract and move large volumes of data between Oracle databases. A
more detailed example of using this feature to extract and transport data is provided
in Chapter 13, "Transportation in Data Warehouses". Oracle recommends that you use
transportable tablespaces whenever possible, because they can provide considerable
advantages in performance and manageability over other extraction techniques.
La implementación exitosa de DWH puede traer enormes beneficios a la organización incluyendo:
• Alto retorno de inversión potencial. Una organización puede comprometer una alta cantidad de
recursos para asegurar la implementación exitosa del DWH y el costo puede variar enormemente
de decenas a millones de USD dependiendo de la variedad de soluciones técnicas disponibles.
Sin embargo, un estudio de IDC (International Data Corporation) reportó que los proyectos de DWH
entregados en un promedio de tres años el retorno de inversión (ROI) es del 401% (IDC 1996).
Además, un estudio mas reciente de IDC en análisis financiero (que son herramientas analíticas que
accesan a un DWH) entregas de en promedio un año dan un ROI del 431% (IDC, 2002).
• Ventaja competitiva. El alto retorno en inversión para estas compañías que tienen
implementaciones exitosas de un DWH es evidente en la enorme ventaja competitiva que
acompañan estas tecnologías. La ventaja competitiva es ganada por medio de los tomadores de
decisiones que accesan la información que puede revelar previamente no disponibilidad,
desconocimiento, información no explotada, con por ejemplo clientes, tendencias y demandas.
• Incrementa la productividad de los tomadores de decisiones. DWH incrementa la productividad de

los tomadores de decisiones corporativos creando e integrando bases de datos de información
histórica consistente y orientada a sujetos. Esto integra la información de sistemas múltiples y tal ves
incompatibles dentro de una forma que proporciona una vista consistente de la organización. Por
medio de la transformación de los datos en información significativa. un DWH permite a los
tomadores de decisiones realizar un análisis mas sustantivo, exacto y consistente.
El modelo de datos OLAP es multidimensional. La información esta representada por un arreglo
multidimensional de medidas numéricas. tales como ventas o ganancias las cuales son útiles para
análisis. Las dimensiones únicamente determinan la medida. En las ventas del DWH, por ejemplo,
dimensiones interesantes pueden incluir hora de venta, localidad y producto. Cada dimensión puede
representarse por uno o mas atributos de la dimensión.
Por ejemplo, la dimensión de tiempo la cual es de particular interés para las aplicaciones OLAP puede
tener atributos de fecha, semana, mes, cuarto (trimestre) y año. Los atributos de las dimensiones son
frecuentemente organizados en forma jerárquica como año  cuarto  mes  semana de la industria
 categoría  producto.
Las operaciones OLAP habilitan a los usuarios finales, tales como analistas financieros a manipular
información multidimensional con una interface poderosa de una hoja de calculo.
Muchas de estas operaciones tratan con agregación (aggregation). Agregación de una medida a lo largo
de un subconjunto de las dimensiones es hecho por pivoteo (reorientación) de la vista multidimensional
de la información.
Por ejemplo, consideremos un arreglo tridimensional de la figura 4. Pivoteando este arreglo a lo largo de
las dimensiones de localidad y tiempo podrá producir un arreglo bidimensional en el cual cada punto
(x,y) da las ventas agregadas para la localidad x en el tiempo y.
Aggregation de una medida a diferentes niveles de una jerarquía de dimensión esta soportada por
operaciones de roll-up y drill-down. Roll-up incrementa el nivel de agregación por medio de mover la
jerarquía de la dimensión. Por ejemplo, podemos hacer una operación de roll-up a lo largo de la
dimensión del tiempo para agregar ventas por año. Una operación drill-down es la inversa de la roll-up y
es útil para incrementar el nivel de detalle. Otra operación popular es slice and dice la cual corresponde
a seleccionar un proyecto en un subconjunto de dimensiones. Otras operaciones tratan con atributos
de rango y calculo.
Figura 4. Multidimensional data
Time 2008
2007
Skateboard 50 75 25
Product Quad roller 100 25 100
Inline roller 75 50 75
Paris London New York
Location
La mayoría de los queries OLAP pueden ser expresados en SQL utilizando (SUM, AVG, etc.)
y agrupándolos (GROUP BY). Sin embargo, algunos queries no pueden ser directamente
expresados y requieren extensiones significativas. Este es el caso para queries los cuales
involucran rangos (por ejemplo las diez ciudades con las ventas mas altas).
Hay dos enfoques principales para implementar servidores DWH [Colliant, 1996]. Multidimensional
OLAP (MOLAP) los servers directamente soportan operaciones OLAP en estructuras de datos
multidimensionales, mientras que Relational OLAP (ROLAP) servers, extienden DB relacionales para
soportar operaciones OLAP.
Los servers MOLAP almacenan la información en estructuras de datos multidimensionales que están
dedicadas a operaciones OLAP. La estructura de datos típicamente tiene dos niveles para tratar con
grandes conjuntos de datos que no caben en la memoria principal. Con esta estructura de datos las
operaciones OLAP se pueden procesar mas eficientemente en memoria [Finkelstein, 1995]. Sin
embargo, cambiando el arreglo multidimensional, por ejemplo agregando otra dimensión, requiere una
reconstrucción completa del arreglo. Además, MOLAP servers no pueden escalarse a very large
Databases (VLDB) puesto que el índice principal debe poder estar en memoria principal. Un problema
final es que no hay un modelo de datos multidimensional estándar y los servers MOLAP son
substancialmente diferentes en el direccionamiento de los requerimientos OLAP.
Servidores ROLAP son una extensión de RDBMS o servers intermedios enfrente de RDBMS que
almacenan la información en relaciones. Un arreglo multidimensional es representado por dos tipos de
relaciones. La tabla fact relaciona las dimensiones de las medidas con una relación cuyo primary key es
el conjunto de identificadores de la dimensión. Por ejemplo, el arreglo multidimensional de la figura 4
produce la tabla fact(location_id, time_id, product_id, sales) con la key location_id, time_id, product_
id. Cada dimensión es representada por una tabla de dimensión la cual su llave es el identificador de la
dimensión. Por ejemplo, la dimensión de tiempo produce la relación (time-id, date, week, month,
quarter, year).
Las operaciones OLAP están mapeadas dentro de queries SQL complejos en las tablas fact y dimensión,
las cuales pueden involucrar muchos joins con las operaciones de aggregate y group by. Por lo tanto son
necesarios métodos de acceso eficientes y procesamiento de queries para tratar son relaciones muy
grandes.
Los índices en las tablas de fact y dimensión son importantes. Por lo tanto join indices y sus extensiones
recientes tales como bit-mapped join indices e índices variant son mas eficientes para relacionar
directamente los valores de los atributos en la tabla de dimensiones con las tuplas que se relacionan en
la tabla fact. Como los índices las vistas materializadas son útiles para pre calcular información de
resumen y aggregates. Los temas mas importantes la eficiencia en actualizar las vistas materializadas
usando técnicas incrementales y la transformación de queries en términos de vistas materializadas. Otra
solución complementaria para procesamiento eficiente OLAP es el paralelismo.
Comparación de Sistemas OLTP y Data Warehouse

Un DBMS construido por un OLTP esta considerado generalmente como inadecuado para DWH. Porque
cada sistema esta diseñado con un diferente conjunto de requerimientos en mente. Por ejemplo,
sistemas OLTP esta diseñado para maximizar la capacidad del procesamiento de transacciones, mientras
que warehouses están diseñados para soportar el procesamiento de consultas ad hoc. La siguiente tabla
proporciona un comparativo de las principales características de los sistemas OLTP y sistemas DWH. La
tabla también indica algunas de las mayores tendencias que pueden alterar las características del DWH.
Una de tales tendencias es el de moverse hacia data warehousing de tiempo real (RT).
Una organización tendrá normalmente un numero de diferentes sistemas OLTP para procesos de
negocio tales como control de inventarios, facturación a clientes y puntos de venta. Estos sistemas
generan información operacional que es detallada, actual y sujeta a cambio. Los sistemas OLTP están
optimizados para un gran numero de transacciones que son predecibles, repetitivas y actualizadas
intensivamente. La información OLTP esta organizada de acuerdo a los requerimientos de las
transacciones asociadas con las aplicaciones de negocio y soportan decisiones del día a día de un gran
numero de usuarios operacionales concurrentes.
En contraste, una organización podrá normalmente tener un solo DWH, el cual almacena la información
que es histórica, detallada, y resumida de varios niveles y raramente sujeta a cambio siendo
complementada con información nueva.
El DWH esta diseñando para soportar relativamente un numero bajo de transacciones que no son
predecibles en naturaleza y requieren respuestas a consultas ad hoc, no estructuradas y heurísticas. La
información del warehouse esta organizada de acuerdo a los requerimientos de consultas potenciales y
soporta los requerimientos analíticos de un reducido numero de usuarios.
Características Sistemas OLTP Sistemas DWH
Propósito Soporta procesamiento operacional Soporta procesamiento analítico

principal
Tipo de Actual Histórica (pero la tendencia es también incluir
información información actual)
Latencia de la Tiempo real Depende de la longitud del ciclo para suplementos de
información información de warehouse (pero la tendencia es hacia
suplementos de tiempo real)
Granularidad Información detallada Información detallada ligeramente y altamente resumida
de la
información
Procesamiento patrones de datos predecibles de Patrones menos predecible de consulta de datos nivel
de información inserciones, borrados, actualizaciones de desempeño medio a bajo de transacciones
y consultas. Alto nivel de rendimiento
de transacciones
Reporteo Predecible unidimensional, Impredecible, multidimensional, reporteo dinámico
relativamente estático, reporteo fijo
Usuarios Sirve a un gran numero de usuarios Sirve a un numero reducido de usuarios gerenciales
operativos (pero la tendencia es también hacia usuarios
operacionales con requerimientos de soporte analítico)
Aunque sistemas OLTP y DWH tienen diferentes características y están construidos con diferentes
propósitos en mente, estos sistemas están relacionados muy de cerca en que los sistemas OLTP
proporcionan la fuente de datos para el warehouse. El principal problema de esta relación es que la
información almacenada por los sistemas OLTP puede ser inconsistente, fragmentada y sujeta a
cambios, contener duplicados o entradas faltantes. Como tal, la información operacional debe ser
“limpiada” antes de que sea utilizada en el DWH.
Sistemas OLTP no están construidos para dar respuesta rápidamente a consultas personalizadas. Sino
que también tienden a no almacenar información histórica la cual es necesaria para analizar tendencias.
Básicamente OLTP ofrece grandes cantidades de datos crudos, los cuales no son fáciles de analizar. El
DWH proporciona queries mas complejos para ser resueltos además de solo simples aggregations tal
como, “Cual es el promedio del precio de venta por propiedades en las principales ciudades de UK?” Los
tipos de consultas que los DWH esperan contestar tienen un rango de relativamente simple a altamente
complejo y son dependientes a los tipos de herramientas de acceso que utilizan usuarios finales.
Problemas con DWH

Los problemas asociados con el desarrollo y administración de DWH son los siguientes:
Desestimación de recursos para información ETL (Extraction, Transform and Loading).
Muchos programadores desestiman el tiempo requerido para extraer, transformar y cargar (ETL) la
información dentro del DWH. Este proceso puede contar por una proporción del tiempo significativa del
tiempo de desarrollo, aunque mejores herramientas de ETL ayudan a reducir el tiempo y el esfuerzo.
Problemas escondidos de los sistemas fuente.
Problemas escondidos asociados con los sistemas fuente alimentan el DWH y pueden ser identificados
posiblemente después de años de no ser detectados. El desarrollador debe decidir cuando solucionar el
problema en el DWH y/o en el sistema fuente. Por ejemplo cuando capturan los datos de una nueva
propiedad , ciertos campos pueden ser nulos, la cual puede resultar en que capturen datos incompletos
aun estando disponibles.
Datos requeridos no capturados

Incremento de las demandas de los usuarios finales
Homogenización de datos
Alta demanda de recursos
Propiedad de la información
Alto mantenimiento
Duración de proyectos a mucho tiempo
Complejidad de la integración
Real-Time Data Warehouse

Cuando iniciaron los DWH fueron reconocidos como sistemas que almacenaban información histórica.
Fue aceptado que la información estuviera actualizada en forma semanal y en ese tiempo fue
considerado suficiente para cumplir las necesidades de los tomadores de decisiones corporativos. Sin
embargo, en nuestros días la historia es diferente.
En fechas recientes, la tecnología de DWH ha sido desarrollada para permitir una sincronización mas
cercana entre la información operacional y la del DWH y estos sistemas son definidos como DWH de
tiempo real real-time (RT) o muy cercanos al tiempo real near-real time (NRT)
Sin embargo, tratando de reducir el retraso (por ejemplo latencia de datos) entre la creación de la
información operacional y la inclusión de la información en el DWH ha colocado demandas adicionales
en la tecnología de DWH. Los problemas principales en DWH RT y NRT incluyen:
• Habilitación de información fuente de ETL RT. El problema para RT DWH es reducir el la ventana de
ETL para permitir la carga RT/NRT con el mínimo tiempo fuera para los usuarios DWH.
• El modelado de las tablas fact RT. Este problema con modelado de datos RT dentro del DWH es
conocido como integrar la información RT con la otra información variada agregada contenida
previamente en el DWH.
• OLAP queries versus changing data. El problema es que las herramientas OLAP asumen que la
información es estática y no tiene cambios. Las herramientas no tienen protocolos para tratar con
información que esta siendo actualizada durante el ciclo de vida del query.
• Scalability and query contention. El problema con la escalabilidad y la contención de queries fue
una de las razones principales de separar sistemas operacionales de sistemas analíticos.
En esta sección examinaremos herramientas y tecnologías asociadas con la construcción y
administración de un DWH, en particular nos enfocaremos en los temas asociados con la integración de
estas herramientas.
Extraction, Transformation and Loading (ETL)

Uno de los beneficios mas comunes asociados con data warehouses empresariales (EDW) es que esta
centralización de los sistemas proporcionan una vista integral de la información corporativa. Sin
embargo, el logro de esta vista de información puede ser muy complicado y costoso en tiempo. La
información destinada para un data warehouse empresarial debe ser extraída de uno o mas bases
origen, transformarlas en una forma fácil de analizar y consistente con la información que ya existe en el
DWH y finalmente cargada al EDW. Este proceso completo es conocido como el proceso de extracción,
transformación y carga (ETL) y es un proceso critico en cualquier proyecto de DWH.
Extraction
Los pasos de extracción toman los datos de una o mas bases de datos origen para el EDW, estos
orígenes típicamente incluyen bases de datos OLTP pero también pueden incluir orígenes tales como
bases de datos personales, hojas de calculo, archivos ERP (Enterprise Resource Planning) y archivos de
log de utilización de web, la información fuente es normalmente interna pero también puede incluir
fuentes externas tales como los sistemas utilizados por proveedores y/o clientes.
LA complejidad del paso de extracción depende de que tan similares o diferentes son los sistemas
origen del EDW. Si la información de origen esta bien documentada, mantenida, conforme a los
formatos empresariales y usa la misma o similar tecnología entonces el proceso de extracción será
directo. Sin embargo desde el otro extremo es para sistemas origen que están poco documentados y
con diferentes formatos y tecnologías. En este caso el proceso ETL será muy complejo. El proceso de
extracción copia la información a un almacenamiento temporal conocido como el ODS o staging area
(SA).
Temas adicionales con el proceso de extracción incluye establecer la frecuencia de las extracciones de
cada sistema origen al EDW, monitoreando cada modificación del sistema fuente para asegurar que el
proceso de extracción permanezca valido y monitoreando cualquier cambio en el desempeño o la
disponibilidad de los sistemas origen los cuales puedan tener un impacto en este proceso.
Transformation
El paso de transformación aplica una serie de reglas o funciones para información extraída, la cual
determina como será utilizada esta información para analizarla y pueda involucrar transformaciones
tales como sumarizado, codificación, fusiones, división, calculo de datos y creación de llaves sustitutas
(surrogate keys) la salida de las trasformaciones es información limpia y consistente con la información
dentro del warehouse, y además esta en una forma lista para ser analizada por los usuarios en el
warehouse. Aunque la información resumida esta mencionada como posible transformación, es
recomendado comúnmente que la información dentro del warehouse tenga el menor grado de
granularidad posible. Esto proporciona a los usuarios que puedan realizar consultas en la información
del EDW que sean capaces de profundizar con la información mas detallada.
Loading
La carga de la información dentro del warehouse puede ocurrir después de todas las transformaciones o
una parte de ellas. Como la información se carga dentro del warehouse, se activan restricciones
adicionales definidas en el esquema de la base de datos (por ejemplo unicidad, integridad referencial, y
campos obligatorios) los cuales también contribuyen al buen desempeño del proceso ETL.
En el warehouse la información puede estar sujeta a sumarizaciones y enviada después a otras bases de
datos asociadas tales como data marts o para alimentar aplicaciones particulares como Customer
Resource Manager (CRM). Temas importantes en el paso de carga son determinar la frecuencia de la
carga y establecer como la carga afectará la disponibilidad del DWH.
Hay bastantes temas asociados a la integración del DWH.
La administración de la metadata es una tarea extremadamente compleja y difícil. Metadata es utilizada
para una variedad amplia de propósitos y su administración es un tema critico para asegurar la
integración exitosa del DWH.
El propósito principal de metadata es el de mostrar la trayectoria de donde vienen los datos, así el
administrador del DWH conoce la historia de cualquier item en el warehouse. Sin embargo, el problema
es que metadata tiene varias funciones dentro del warehouse que relaciona a los procesos asociados
con la trasformación y carga de la información, la administración y generación de consultas del DWH. La
metadata asociada con la transformación y carga de datos debe describir los datos origen y cualquier
cambio que fuera hecho en la información.
Sincronización de metadata
El mayor tema de integración es como sincronizar varios tipos de metadata utilizados a través del DWH.
Las herramientas tan variadas de la generación del DWH y el uso de su propio metadata y para alcanzar
la integración se requiere que esas herramientas sean capaces de compartir la metadata. El desafío es
sincronizar metadata entre diferentes productos de diferentes vendedores utilizando almacenes de
metadata diferente. Por ejemplo si es necesario identificar el item correcto al nivel adecuado de detalle
en otro producto y mapearlo a un item apropiado en el nivel adecuado de otro producto y entonces
resolver cualquier diferencia en el código entre ellos. Esto se repetirá para toda la metadata que tengan
mas de dos productos en común. Además, cualquier cambio a la metadata (inclusive metadata) de un
producto necesita ser transmitido al otro producto. La tarea de sincronización de dos productos es
altamente compleja y por lo tanto repetir continuamente este proceso para todos los productos que
conforman el DWH puede utilizar muchos recursos. Sin embargo se tiene que realizar la integración del
warehouse.
Un data warehouse requiere herramientas para soportar la administración y manipulación de tan
complejo medio ambiente. Estas herramientas son capaces de soportar las siguientes tareas:
• Monitoreo de la carga de información de orígenes múltiples

• Revisión de la integridad y calidad de la información
• Administración y actualización de metadata
• Monitoreo del desempeño de la base de datos para asegurar el tiempo de respuesta eficiente de los
queries y la utilización de recursos
• Auditoria de la utilización del data warehouse para proporcionar la información de regreso al
usuario
• Replicación, subconjuntos y distribución de la información
• Mantener la administración eficiente de la información
• Purgado de información
• Archivo y respaldo de la información
• Implementación de procesos de recuperación en caso de falla
• Administración de la seguridad
Una base de datos que contiene un subconjunto de información corporativa para soportar los
requerimientos analíticos de unidades de negocios en particular (tales como departamento de ventas) o
para soportar usuarios que comparten información de los mismos requerimientos para analizar un
proceso de negocio particular (tales como venta de propiedades).
El data mart esta construido para soportar los requerimientos analíticos de un grupo en particular de
usuarios y proporcionando este soporte, el data mart solo almacena un subconjunto de información
corporativa. Se tienen dos metodologías para los data marts: Kimball’s Business Dimensional Lifecycle
(Kimball, 2006) y Inmon’s Corporate Information Factory (CIF) methodology (Inmon, 2001).
En la metodología de Kimball el datamart es la implementación física de un esquema simple (modelo
dimensional) modelado en un proceso de negocio en particular (por ejemplo la venta de propiedades).
Los usuarios en el data mart de Kimball se pueden distribuir a través de la empresa pero compartir los
mismos requerimientos para analizar un proceso de negocio particular. Cuando todos los procesos de
negocio de una empresa están representados como data marts, la integración de data marts forman el
EDW.
Con la metodología de Inmon un data mart es la implementación física de la base de datos que soporta
los requerimientos analíticos de una unidad de negocio en particular (tal como el departamento de
ventas) en la organización. El data mart de Inmon recibe información del EDW.
Como se describió previamente, la relación entre data marts es con su asociado DWH es dependiente
en cual metodología se utiliza para construir el data mart. Por esta razón un data mart puede estar solo,
asociado con otros data marts a través de dimensiones conformadas o ligado centralmente al EDW. Por
lo tanto las arquitecturas del data mart es la primera capa (el DWH proporciona información para los
data marts), el data mart en si es la segunda capa, y la workstation del usuario es la tercera capa.
Kimball DW/BI Lifecycle Methodology
Razones para crear data marts
Hay varias razones para crear data marts, las cuales incluyen:
• Para proporcionar acceso a los usuarios a la información que necesitan analizar mas
frecuentemente.
• Para proporcionar información de forma que iguale la vista colectiva de la información por un grupo
de usuarios en el departamento, o grupo de usuarios interesados en un proceso de negocio en
particular.
• Para mejorar el tiempo de respuesta de los usuarios finales debido a la reducción de datos a ser
procesados.
• Proporcionar una estructura de la información adecuada como son enviados los requerimientos de
las herramientas de acceso de los usuarios finales tales como herramientas OLAP y de data mining,
las cuales pueden requerir sus propias estructuras de bases de datos internas.
• Los data marts generalmente utilizan menos información que el proceso de ETL es menos
complicado y por consiguiente la implementación y puesta en marcha del data mart es las simple.
• El costo de implementación de data marts (en tiempo, dinero y recursos) es normalmente menor
que los establecidos en el EDW.
• Los usuarios potenciales de un data mart son mas claramente definidos y pueden ser mas fácilmente
dirigidos para obtener soporte de un proyecto de data mart en lugar de un proyecto de EDW.
Oracle Database 10g/11g es una plataforma exhaustiva de bases de datos para DWH y business
intelligence que combina desempeño, escalabilidad, análisis a fondo integrado líder en la industria,
integración incluida y calidad de la información, todo esto en una sola plataforma ejecutándose en una
infraestructura confiable y a bajo costo. Oracle proporciona funcionalidad para data warehouses y data
marts con funcionalidades robustas de particionamiento, proporcionando escalabilidad a cientos de Tb y
optimización de procesamiento de queries innovador, también proporciona una plataforma única e
integrada para análisis por medio de OLAP incrustado, data mining y capacidades estadísticas
directamente dentro de la base de datos. Incluye capacidades ETL con el Oracle Warehouse Builder. Así
como también:
• Vistas materializadas
• Automated Workload Repository (AWR) que es un componente critico para las herramientas
predictivas del DWH
• STAR query optimization que soporta la creación de queries analíticos complejos
• Multinivel de particionamiento de tablas e índices
• Asynchronous Change Data Capture (CDC). Proporciona extracciones incrementales, así que solo la
información modificada es extraída para ser cargada en el DWH.
• Oracle Streams. mecanismos de alimentación basados en streams pueden capturar los cambios de la
información de bases de datos operacionales y enviarlas al DWH destino.
• Read-only tablespaces mejora el desempeño pues no modifica datos estáticos.
• Automatic Storage Management (ASM)
• Advanced data buffer management. Utilizando múltiples tamaños de bloques
La principal ventaja y desventaja asociada con el desarrollo del EDW utilizando Inmon’s CIF methodology
y Kimball’s Business Dimensional Lifecycle
Metodología Principal ventaja Principal desventaja
Inmon’s corporate Potencia una vista Proyecto largo y complejo que

Information Factory consistente y exhaustiva de puede fallar en la entrega de valor
los datos empresariales dentro del periodo de tiempo
permitido o presupuestado
Kimball’s Business Proyectos a escala reducida Como los data marts pueden
Dimensional significa que es mas valioso desarrollarse potencialmente en
Lifecycle demostrar valor dentro del secuencia por diferentes equipos
periodo de tiempo permitido de desarrollo utilizando diferentes
o presupuestado sistemas, la tarea principal de
proporcionar una vista consistente
y exhaustiva de la información
corporativa puede no ser alcanzada
nunca
Modelado de dimensionalidad una técnica de diseño lógico que tiene como objetivo presentar la
información de manera estándar, intuitiva que proporciona el acceso de alto desempeño.
Cada modelo dimensional (DM) esta compuesto de una tabla con una llave primaria compuesta,
llamada la tabla fact y un conjunto de tablas mas pequeñas llamadas tablas de dimensión. Cada tabla
de dimensión tiene una simple (no compuesta) llave primaria que corresponde exactamente a uno de
los componentes de la llave compuesta en la tabla fact. En otras palabras la llave primaria de la tabla
fact esta hecha hasta de dos o mas llaves externas. Esta característica en forma de “estrella” es llamado
el esquema estrella o star join.
Esquema estrella Un modelo de datos dimensional que tiene una tabla fact en el centro rodeada por
tablas “desnormalizadas” de dimensión.
El esquema estrella explota las características de las tablas factual tales como estar generadas por
eventos que ocurrieron en el pasado, y que no son muy comúnmente actualizadas, sin embargo tienen
que ser analizadas. Como la mayor parte de los datos en el warehouse esta representada como facts, las
tablas fact pueden ser extremadamente grandes relativamente comparadas con las tablas dimensión.
Como tal es importante tratar la información fact como de solo lectura lo cual no la cambiará a lo largo
del tiempo. Las tablas fact mas útiles contienen una o mas medidas numéricas o “facts” que ocurren
para cada registro. En la figura de la siguiente pagina las facts son offerPrice, sellingPrice,
saleCommission y saleRevenue. Las facts mas útiles en la tabla fact son numéricas y additive, puesto
que las aplicaciones warehouse casi nunca accesan a un solo registro, al contrario accesan a cientos,
miles o inclusive millones de registros a la vez y la cosa mas importante que hacer es la mayor parte de
registros agregarlos (aggregate).
Las tablas de dimensión generalmente por el contrario, generalmente contienen información descriptiva
textual. Los atributos de las dimensiones son utilizadas como restricciones en los queries del data
warehouse. Por ejemplo el esquema estrella mostrado puede soportar queries que requieren acceso a
ventas de propiedades en Glasgow usando el atributo city de la tabla PropertyForSale.
Dimension Tables
Dimension Tables Property/ForSale
Time
----------------------------
----------------------------
propertyID(FK)
timeID (FK)
proportyNo
day
type
week
street
month
city
year
postcode
Fact Table region
country
Property Sale
--------------------------------
Branch timeID (FK)
---------------------------- propertyID(FK) ClientBuyer
branchID(FK) branchID(FK) ----------------------------
branchNo clientID(FK) clientID(FK)
branchType PromotionID(FK) clientNo
city staffID(FK) clientName
region ownerID(FK) clientType
country otherPrice city
sellingPrice region
saleCommission country
saleRevenue
Promotion
---------------------------- Staff
promotionID(FK) Owner ----------------------------
promotionNo ---------------------------- staffID(FK)
promotionName ownerID(FK) staffNo
promotionType ownerNo staffName
ownerName position
ownerType sex
city city
region region
Star schema (dimensional model) country country
Snowflake schema. un modelo dimensional de datos que tiene una tabla fact en el centro, rodeada de
tablas de dimensión normalizada. Esta es una variación del esquema estrella llamado snowflake schema
el cual proporciona que las dimensiones tengan otras dimensiones. Por ejemplo podemos normalizar la
información de la localidad (atributos de city, región y país) en la tabla de dimensión Branch para crear
dos nuevas tablas de dimensión llamadas City y Region, esto se muestra en la siguiente figura
Fact Table
Dimension Tables Property Sale
--------------------------------
Branch timeID (FK)
---------------------------- propertyID(FK)
branchID(FK) branchID(FK)
branchNo clientID(FK)
branchType PromotionID(FK)
city (FK) staffID(FK)
ownerID(FK)
otherPrice
sellingPrice
saleCommission
City saleRevenue
----------------------------
city (FK)
region(FK)
Region
----------------------------
region(PK)
country
Parte del Star schema (dimensional model) con la versión normalizada de la tabla Branch
Starflake schema. un modelo dimensional de datos que tiene una tabla fact en el centro, rodeada de
tablas de dimensión normalizadas y desnormalizadas.
Algunos modelos dimensionales usan una combinación de esquemas estrella desnormalizados y
snowflake normalizado. Esta combinación de esquemas estrella y snowflake es llamado esquema
starflake. Algunas dimensiones pueden representarse en ambas formas para abastecer requerimientos
para distintos tipos de queries. Cuando el esquema es star, snowflake o starflake las formas predecibles
y estándar de los modelos dimensionales ofrecen ventajas importantes dentro del medio ambiente del
data warehouse incluyendo:
Eficiencia. La consistencia de estructura de base de datos subyacente permite un acceso mas eficiente a
la información por varias herramientas incluyendo report writers y query tools.
Habilidad para manejar requerimientos cambiantes. El modelo dimensional puede adaptarse a los
cambios en los requerimientos de los usuarios, como todas las dimensiones son equivalentes en
términos de proporcionar acceso a la tabla fact. Esto significa que el diseño es mejor capaz de soportar
consultas de usuarios personalizadas.
Extensibilidad. El modelo dimensional es extensible, por ejemplo cambios típicos soportados por el
modelo deben incluir: a) agregar nuevos facts, tanto como sean consistentes con la granularidad
fundamental de la tabla fact existente; b) agregar nuevas dimensiones, tantas como sean valores
simples de una dimensión definida por cada registro fact existente; c) agregar nuevos atributos de
dimensión y d) detallar los registros existentes de dimensión en un menor nivel de granularidad de
cierto punto en el tiempo en adelante.
Habilidad de modelar situaciones de negocio comunes. Hay una gran crecimiento de la cantidad de
enfoques para manejar situaciones en el modelado común en el mundo de los negocios. Cada una de
estas situaciones tienen un conjunto de alternativas bien conocidas que pueden ser programados
específicamente en report writers, query tools y otras interfaces de usuario; por ejemplo, dimensiones
de cambio lento son dimensiones constantes como Branch o Staff.
Procesamiento de queries predictivo. Aplicaciones de Data warehouse que realizan drill down
simplemente agregan mas atributos de dimensión en un solo modelo dimensional.
Comparación entre Dimensional Model y modelo Entidad relación

El modelado de Entidad relación es la técnica de identificar relaciones entre entidades. La tarea principal
del modelado de Entidad Relación es remover la redundancia en la información. Esto es un beneficio
muy grande para procesamiento de transacciones, puesto que las transacciones son mas simples y
determinísticas. Por ejemplo la transacción que actualiza la dirección de un cliente, normalmente accesa
un solo registro en la tabla Clientes. Este acceso es extremadamente rápido y utiliza un índice como su
llave primaria clientNo. Sin embargo en realizar el procesamiento de transacciones eficiente, tales bases
de datos no pueden soportar consultas personalizadas de usuarios finales de manera eficiente y
fácilmente. Aplicaciones tradicionales de negocio tales como ordenes de compra, control de inventarios
y facturación requieren de muchas tablas con numerosos joins entre ellas. Un modelo Entidad Relación
para una empresa puede llegar a tener miles de entidades lógicas mapeando sus miles de tablas físicas.
El modelado de datos tradicional de Entidad Relación no soporta el data warehousing el cual es intuitivo
y con un alto desempeño en la obtención de información.
La llave para entender la relación entre modelos dimensionales y modelos de Entidad Relación es que
un solo modelo Entidad Relación normalmente se descompone dentro de múltiples modelos
dimensionales. Los modelos múltiples dimensionales están asociados a través de tablas de dimensión
compartidas.
Área funcional Ejemplo de aplicaciones OLAP
Finanzas Presupuestos, costos, análisis de

desempeño financiero, modelado
financiero
Ventas Análisis de ventas y pronostico de ventas
Marketing Análisis de estudio de mercado,

proyecciones de ventas, análisis de
promociones, análisis de clientes y
segmentación de mercados/ clientes
Manufactura Planeación de producción y análisis de
defectos
Tabla Reglas de Codd para herramientas OLAP
1 Vista conceptual multidimensional

2 Transparencia
3 Accesibilidad
4 Desempeño de reporteo consistente
5 Arquitectura cliente-servidor
6 Direccionalidad genérica
7 Administración de matrices distribuidas dinámicamente
8 Soporte multi usuario
9 Operaciones sobre dimensionales sin restricciones
10 Manipulación de datos de manera intuitiva
11 Reporteo flexible
12 Niveles de dimensión y aggregation ilimitados
La mayor limitante del SQL para analistas financieros es la dificultad de utilizar SQL como respuesta a
consultas de negocio rutinarias o de calcular el cambio de porcentaje en valores entre meses y años
atrás o el de calcular promedios, sumas acumuladas y otras funciones estadísticas. En respuesta a estas
limitaciones ANSI adopto un conjunto de funciones OLAP como extensiones de SQL que puedan
habilitar estos cálculos que serian casi imposibles solo con SQL. IBM y Oracle propusieron estas
extensiones a principios de 1999 y fueron publicados en la versión SQL:2003 y después en SQL:2008.
Estas extensiones son conocidas colectivamente como el “paquete OLAP” e incluye las siguientes
características del leguaje SQL como aparece en el “SQL Feature Taxonomy Annex” en el documento
ISO/IEC 8075-2 (ISO,2008a):
Característica T431, “Extended Grouping capabilities”;
Característica T611, “Extended OLAP operators”
Capacidades extendidas de agrupamiento

Aggregation es una parte fundamental del OLAP. Para mejorar las capacidades de aggregation el SQL
estándar proporciona extensiones con las clausulas GROUP BY tales como funciones ROLLUP y CUBE.
ROLLUP soporta cálculos usando aggregations tales como SUM, COUNT, MAX, MIN y AVG al
incrementar los niveles de aggregation de lo mas detallado al gran total. CUBE es similar al ROLLUP,
habilitando una sola sentencia para calcular todas las posibles combinaciones del aggregation. CUBE
puede generar la información necesaria en reportes de tabulación cruzada con un solo query.
Las extensiones ROLLUP y CUBE especifican exactamente el agrupamiento de intereses en la clausula
GROUP BY y produce un solo conjunto de resultados que es equivalente a UNION ALL pero agrupado en
renglones.
Extensión ROLLUP a GROUP BY
ROLLUP habilita una sentencia SELECT para calcular niveles múltiples de subtotales a través de un grupo
especifico de dimensiones. El ROLLUP aparece en la clausula GROUP BY en la sentencia SELECT
utilizando el siguiente formato:
SELECT ..... GROUP BY ROLLUP(columnlist)
ROLLUP crea subtotales que se enrollan desde el nivel mas detallado hacia un gran total, siguiendo la
lista de columnas especificadas en la clausula ROLLUP. El ROLLUP primero calcula los valores estándares
del aggregate especificado en la clausula GROUP BY entonces crea subtotales progresivos llegando hasta
el gran total.
ROLLUP crea subtotales por nivel n+1, donde n es el numero de columnas agrupadas. Por ejemplo si el
query especifica un conjunto de columnas agrupado por ROLLUP de propertyType, yearMonth y city
(n=3), el resultado es el conjunto que incluirá renglones en 4 niveles de aggregation.
Ejemplo:
Muestre los totales de ventas de casas y pisos por sucursal localizadas en Aberdeen, Edinburgh, o
Glasgow, para los meses de septiembre y octubre del 2008
SELECT propertyType, yearMonth, city, SUM(saleAmount) AS sales

FROM Branch, PropertyForSale, PropertySale
WHERE Branch.branchNo = PropertySale.branchNo
AND PropertyForSale.propertyNo = PropertySale.propertyNo
AND PropertySale.yearMonth IN (‘2008-08’, ‘2008-09’)
AND Branch.city IN (‘Aberdeen’, ‘Edinburgh’, ‘Glasgow’)
GROUP BY ROLLUP(propertyType, yearMonth, city)
La salida del query se muestra a continuación
• Renglones Aggregation regulares que serán producidos por GROUP BY sin utilizar ROLLUP
• Aggregation con subtotales de primer nivel a través de city para cada combinación de propertyType y
yearMonth
propertyType yearMonth city sales
flat 2008-08 Aberdeen 115432
flat 2008-08 Edinburgh 236673
flat 2008-08 Glasgow 7664
flat 2008-08 359669
flat 2008-09 455635
flat 815304
house 2008-08 Aberdeen 77987
house 2008-08 Edinburgh 135670
house 2008-08 Glasgow 4765
house 2008-08 218422
house 2008-09 247713
466135
Grand Total 1281439
Extensión CUBE por GROUP BY
El CUBE toma un conjunto especifico de columnas agrupadas y crea subtotales para todas las
combinaciones posibles. CUBE aparece en la clausula GROUP BY en la sentencia SELECT usado de la
siguiente forma:
SELECT ...... GROUP BY CUBE(columnlist)
En términos de análisis multidimensional CUBE genera todos los subtotales que pueden ser calculados
por el cubo de datos con las dimensiones especificas. Por ejemplo si el cubo especifico
CUBE(propertyType, yearMonth, city), el resultado serán todos los valores incluidos en la sentencia
ROLLUP mas combinaciones adicionales. Para el ejemplo anterior los totales para city para tipos de
propiedad combinados no son calculados por la clausula ROLLUP(propertyType, yearMonth, city), pero
son calculados para CUBE(propertyType, yearMonth, city). Si n columnas están especificadas por un
CUBE serán 2n combinaciones de los subtotales.
Cuando utilizar CUBE. CUBE puede ser utilizado en cualquier situación que requiera utilizar reportes
tabulares cruzados estos se pueden generar con un sola sentencia SELECT utilizando CUBE. Como
ROLLUP, CUBE puede ser útil en la generación de tablas sumarizadas.
CUBE es típicamente mas utilizado en queries que usan columnas de múltiples dimensiones en lugar de
columnas representando diferentes niveles en una sola dimensión. Por ejemplo un reporte requerido
tabulador cruzado común puede necesitar subtotales para todas las combinaciones de propertyType,
yearMonth y city. Estas son tres dimensiones independientes y el análisis de todas las posibles
combinaciones de subtotales es trivial. En contraste un tabulador cruzado que muestre todas las
combinaciones posibles del year,Month y day podrían tener bastantes valores de interés limitado,
puesto que hay una jerarquía natural en la dimensión de tiempo (time).
Muestre todas los subtotales posibles para ventas de propiedades por sucursal (branch) en Aberdeen,
Edinburgh y Glasgow para los meses de agosto y septiembre del 2008
Reemplazamos la función ROLLUP del ejemplo anterior con la función CUBE.
SELECT propertyType, yearMonth, city, SUM(saleAmount) AS sales

FROM Branch, PropertyForSale, PropertySale
AND PropertyForSale.propertyNo = PropertySale.propertyNo
AND PropertySale.yearMonth IN (‘2008-08’, ‘2008-09’)
AND Branch.city IN (‘Aberdeen’, ‘Edinburgh’, ‘Glasgow’)
GROUP BY CUBE(propertyType, yearMonth, city)
La salida se muestra en la siguiente tabla
Los renglones mostrados en negritas son comunes a los resultados producidas por ambas funciones
ROLLUP y CUBE. Sin embargo la clausula CUBE(propertyType, yearMonth, city), donde n = 3 produce 23
= 8 niveles de aggregation.
flat 2008-08 359669
flat 2008-09 455635
flat Aberdeen 239212
flat Edinburgh 559673
flat Glasgow 16419
flat 815304
house 2008-08 218422
house 2008-09 247713
house Aberdeen 154308
house Edinburgh 302173
house Glasgow 9654
house 466135
2008-08 Aberdeen 193419
2008-08 Edinburgh 372243
2008-08 Glasgow 12429
2008-08 578091
2008-09 Aberdeen 200101
2008-09 Edinburgh 489603
2008-09 Glasgow 13644
703348
Aberdeen 393520
Edinburgh 861846
Glasgow 26073
Grand Total 1281439
Operaciones elementales OLAP
Las operaciones elementales OLAP del paquete OLAP del SQL estándar soportan una variedad de
operaciones tales como clasificación y calculo de ventanas. Funciones de rango incluyen distribuciones
cumulativas, rango de porcentaje, y N-tiles. Ventanas proporcionan los cálculos de aggregations
acumulados y en movimiento usando funciones tales como SUM, AVG, MIN y COUNT.
Funciones de clasificación
Una función de clasificación calcula el rango de un registro comparado con otros registros en el conjunto
de datos basados en los valores del conjunto de medidas. Hay varios tipos de funciones de clasificación,
incluyendo RANK y DENSE_RANK. La sintaxis para cada función de clasificación es como sigue:
RANK( ) OVER (ORDER BY column_list)

DENSE_RANK( ) OVER (ORDER BY column_list)
La diferencia entre RANK y DENSE_RANK es que DENSE_RANK no deja ningún hueco en la clasificación
secuencial cuando hay ligas para la clasificación. Por ejemplo, si tres sucursales ligan para un segundo
lugar en términos de las ventas totales de propiedades, DENSE_RANK identifica todas las tres en
segundo lugar con la siguiente sucursal en tercer lugar. La función RANK también identifica tres
sucursales en segundo lugar, pero la siguiente sucursal esta en quinto lugar.
Ejemplo:
Clasifique las ventas totales de propiedades por sucursal en Edinburgh
Primero calculamos las ventas totales para las propiedades en cada sucursal en Edinburgh y entonces se
clasifican los resultados. Este query accesa las tablas Branch y PropertySale.
SELECT branchNo, SUM(saleAmount) AS sales
RANK() OVER (ORDER BY SUM(salesamount)) DESC AS ranking,
DENSE_RANK() OVER (ORDER BY SUM(salesamount)) DESC AS dense_ranking
FROM Branch, PropertyForSale
AND Branch.city = ‘Edinburgh’
GROUP BY (BranchNo)
branchNo sales ranking dense_ranking

B009 120,000,000 1 1
B018 92,000,000 2 2
B022 92,000,000 2 2
B028 92,000,000 2 2
B033 45,000,000 5 3
B046 42,000,000 6 4
Calculo de ventanas
Se puede utilizar para calcular aggregates acumulados, en movimiento y centrados. Regresa un valor
para cada renglón en la tabla el cual depende de otros renglones en la ventana correspondiente. Por
ejemplo, la ventana puede calcular sumas acumuladas, sumas en movimiento, promedios en
movimiento (o media móvil), min/max en movimiento, así como otras medidas estadísticas. Estas
funciones aggregate proporcionan acceso a las de un renglón de la tabla sin un auto join y puede ser
utilizado solo en las clausulas SELECT y ORDER BY en el query.
Por ejemplo
Muestre las cifras mensuales y los promedios móviles y sumas de tres meses para la venta de
propiedades en la sucursal B003 para los primeros seis meses del 2008
SELECT yearMonth, SUM(saleAmount) AS monthySales, AVG(SUM(salesAmount))

OVER (ORDER BY yearMonth ROWS 2 PRECEDING) AS 3-month moving avg,
SUM(SUM(salesAmount)) OVER (ORDER BY SUM yearMonth ROWS 2 PRECEDING)
AS 3-month moving sum
FROM PropertyForSale
WHERE branchNo = “B003”
AND yearMonth BETWEEN (‘2008-01’ AND ‘2008-06’)
GROUP BY yearMonth
ORDER BY yearMonth;
yearMonth monthlySales 3-month moving 3-month moving sum
avg
2008-01 210,000 210000 210000
2008-02 350,000 280000 560000
2008-03 400,000 320000 960000
2008-04 420,000 390000 1170000
2008-05 440,000 420000 1260000
2008-06 430,000 430000 1290000
Note que los primeros dos renglones para los cálculos de las columnas 3-month moving average y sum
en la tabla de resultado están basados en un tamaño de intervalo menor que el especificado puesto que
la ventana de calculo no puede accesar la información de antes del 2008-01. Esto es por lo tanto,
necesario considerar los diferentes tamaños de la ventana encontrados en los bordes del resultado
dependiendo el query proporcionado. En otras palabras se tiene que modificar el query para lograr los
resultados requeridos.
Oracle SQL analytical functions
Type USED FOR
Ranking Calculating ranks, percentiles and N-tiles of the values in a result set
Windowing Calculating cumulative and moving aggregates. Works with these
functions: SUM, AVG, MIN, MAX, COUNT, VARIANCE, STDDEV,
FIRST_VALUE, LAST_ VALUE and new statistical functions.
Reporting Calculating shares, for example market share. Works with these
functions: SUM, AVG, MIN, MAX, COUNT (with/without DISTINCT),
VARIANCE, STDDEV, RATIO_TO_REPORT and new statistical functions.
LAG/LED Finding a value in a row specified number of rows from a current row
FIRST/LAST First or last value in an ordered group.
Linear Calculating linear regression and other statistics (slope, intercept and so
Regression on)
Inverse The value in a data set that corresponds to a specified percentile
Percentile
Hypothetical The rank or percentile that a row would have if inserted into a specified
Rank and data set.
Distribution
Procesamiento de objetos del modelo multidimensional
El procesamiento es el paso, o serie de pasos, en los que Analysis Services carga
datos de un origen de datos relacional en un modelo multidimensional. Para los
objetos que utilizan el almacenamiento MOLAP, los datos se guardan en el disco en la
carpeta de archivos de base de datos. Para el almacenamiento ROLAP, el
procesamiento se produce a petición, en respuesta a una consulta MDX en un objeto.
Para los objetos que utilizan el almacenamiento ROLAP, el procesamiento hace
referencia a la actualización de la memoria caché antes de devolver los resultados de
la consulta.
De forma predeterminada, el procesamiento aparece cuando se implementa una
solución al servidor. También puede procesar toda o parte de una solución, ya sea de
modo ad hoc mediante herramientas como Management Studio o SQL Server Data
Tools, o según una programación utilizando Integration Services y el Agente SQL
Server. Al realizar un cambio estructural en el modelo, como quitar una dimensión o
cambiar el nivel de compatibilidad, deberá procesarse de nuevo para sincronizar los
aspectos físicos y lógicos del modelo.
Procesamiento y modos de almacenamiento de particiones SQL Server 2014
El modo de almacenamiento de una partición afecta al rendimiento de las consultas y

el procesamiento, a los requisitos de almacenamiento y a las ubicaciones de
almacenamiento de la partición y de su grupo de medida y cubo primario. La
elección del modo de almacenamiento afecta también a las opciones de
procesamiento.
Una partición puede utilizar uno de estos tres modos de almacenamiento básicos:
• OLAP multidimensional (MOLAP)

• OLAP relacional (ROLAP)
•OLAP híbrido (HOLAP)
OLAP relacional (ROLAP)
La arquitectura ROLAP, accede a los datos almacenados en un

datawarehouse para proporcionar los análisis OLAP. La premisa de los
sistemas ROLAP es que las capacidades OLAP se soportan mejor contra
las bases de datos relacionales.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de
datos relacional maneja los requerimientos de almacenamiento de datos,
y el motor ROLAP proporciona la funcionalidad analítica. El nivel de base
de datos usa bases de datos relacionales para el manejo, acceso y
obtención del dato. El nivel de aplicación es el motor que ejecuta las
consultas multidimensionales de los usuarios.
OLAP relacional (ROLAP)
El motor ROLAP se integra con niveles de presentación, a través de los

cuáles los usuarios realizan los análisis OLAP. Después de que el modelo
de datos para el datawarehouse se ha definido, los datos se cargan desde
el sistema operacional. Se ejecutan rutinas de bases de datos para
agregar el dato, si así es requerido por el modelos de datos. Se crean
entonces los índices para optimizar los tiempos de acceso a las consultas.
Los usuarios finales ejecutan sus análisis multidimensionales, a través del
motor ROLAP, que transforma dinámicamente sus consultas a consultas
SQL. Se ejecutan estas consultas SQL en las bases de datos relacionales,
y sus resultados se relacionan mediante tablas cruzadas y conjuntos
multidimensionales para devolver los resultados a los usuarios.
La arquitectura ROLAP es capaz de usar datos precalculados si estos
están disponibles, o de generar dinámicamente los resultados desde los
datos elementales si es preciso. Esta arquitectura accede directamente a
los datos del datawarehouse, y soporta técnicas de optimización de
accesos para acelerar las consultas. Estas optimizaciones son, entre
otras, particionado de los datos a nivel de aplicación, soporte a la
desnormalización y joins múltiples.
Sistemas MOLAP
La arquitectura MOLAP usa unas bases de datos multidimensionales para

proporcionar el análisis, su principal premisa es que el OLAP está mejor
implantado almacenando los datos multidimensionalmente. Por el
contrario, la arquitectura ROLAP cree que las capacidades OLAP están
perfectamente implantadas sobre bases de datos relacionales Un sistema
MOLAP usa una base de datos propietaria multidimensional, en la que la
información se almacena multidimensionalmente, para ser visualizada en
varias dimensiones de análisis.
El sistema MOLAP utiliza una arquitectura de dos niveles: la bases de
datos multidimensionales y el motor analítico. La base de datos
multidimensional es la encargada del manejo, acceso y obtención del
dato.
El nivel de aplicación es el responsable de la ejecución de los
requerimientos OLAP. El nivel de presentación se integra con el de
aplicación y proporciona un interfaz a través del cual los usuarios finales
visualizan los análisis OLAP. Una arquitectura cliente/servidor permite a
varios usuarios acceder a la misma base de datos multidimensional.
Sistemas MOLAP
La información procedente de los sistemas operacionales, se carga en el

sistema MOLAP, mediante una serie de rutinas por lotes. Una vez cargado
el dato elemental en la Base de Datos multidimensional (MDDB), se
realizan una serie de cálculos por lotes, para calcular los datos agregados,
a través de las dimensiones de negocio, rellenando la estructura MDDB.
Tras rellenar esta estructura, se generan unos índices y algoritmos de
tablas hash para mejorar los tiempos de accesos a las consultas. Una vez
que el proceso de compilación se ha acabado, la MDDB está lista para su
uso. Los usuarios solicitan informes a través de la interfase, y la lógica de
aplicación de la MDDB obtiene el dato.
La arquitectura MOLAP requiere unos cálculos intensivos de compilación.
Lee de datos precompilados, y tiene capacidades limitadas de crear
agregaciones dinámicamente o de hallar ratios que no se hayan
precalculados y almacenados previamente.
Caracteristicas
MOLAP ROLAP HOLAP
Almacenamiento de Modelo Base de datos Modelo

agregaciones multidimensional relacional multidimensional
Almacenamiento de Modelo Base de datos Base de datos
datos multidimensional relacional relacional
Facilidad de creación Sencillo Muy sencillo Sencillo
Velocidad de respuesta Buena Regular a baja Buena para

consultas que
posean
agregaciones,
Regular para datos
de bajo nivel
Escalabilidad Problemas de Son mas escalables
escalabilidad
Recomendado para Cubos de uso Datos que no son Si el cubo requiere
frecuente frecuentemente una respuesta
usados rápida
Ventajas y desventajas
Ventajas Desventajas
MOLAP Mejor desempeño en tiempo de respuesta Duplica el almacenamiento de

datos.
Tiempo de latencia
ROLAP Ahorra espacio de almacenamiento El tiempo de respuesta de las
Útil cuando se trabaja con grandes consultas es mayor
volúmenes de información
HOLAP Buen tiempo de respuesta solo para Volúmenes de datos mas grandes
resúmenes de información en la base de datos relacional
• Database Systems A Practical Approach to Design, Implementation, and Management. Fifth Edition.
Thomas Connolly, Carolyn Begg. Pearson. Addison Wesley
• Fundamentos de diseño de bases de datos / Abraham Silberschatz, Henry F. Korth, S. Sudarshan ;
traducción, Fernando Sáenz Pérez, Antonio García Cordero, Jesús Correas Fernández.
• Building a data warehouse for decision support / Vidette Poe ; with contributions by Laura L. Reeves.
• Building the data warehouse / W.H. Inmon.
• Principles of distributed database systems / by M. Tamer Ózsu, Patrick Valduriez.
TEMA
BASES D E D A T O S O RI ENTA D AS A O B J E T O S
AGENDA
• Introducción
• Debilidades de las RDBMS
• Modelo orientado a objetos
• Sistemas Gestores de Bases de Datos Orientadas a Objetos
• The Object-Oriented Database System Manifesto
• Persistencia en OODBMS
• Tipos de Datos Complejos
• Tipos Estructurados y Herencia SQL
• Herencia de Tipos
• Herencia de Tablas
• Tipos Array y Multiconjunto en SQL
• Creación y Acceso a los Valores de los Conjuntos
• Consulta de los Atributos Valorados Como Conjuntos
• Anidamiento y desanidamiento
INTRODUCCION
En la industria de la computación se han tenido

cambios significativos. En los sistemas de bases de
datos se ha tenido una amplia aceptación de los
RDBMS para aplicaciones tradicionales de negocio
tales como procesamiento de ordenes, control de
inventarios, bancos, y reservaciones aéreas. Sin
embargo, RDBMS son inadecuadas para
aplicaciones las cuales sus necesidades son
diferentes de las tradicionales aplicaciones de bases
de datos de negocio. Estas aplicaciones incluyen:
INTRODUCCION
• computer-aided design (CAD);

• computer-aided manufacturing (CAM);
• computer-aided software engineering (CASE);
• networking management systems;
• office information systems (OIS) and multimedia
systems;
• digital publishing;
• geographic information systems (GIS);
• interactive and dynamic Web sites
DEBILIDADES DE LAS RDBMS
Debilidades
Representación pobre de entidades “del mundo real”
Semántica sobrecarga
Soporte pobre para integridad y constraints empresariales
Estructura de datos homogénea
Operaciones limitadas
Difícil manejo de consultas recursivas
Falta de concordancia
Otros problemas con RDBMS asociados con concurrencia,
cambios en el esquema, y acceso navegacional pobre
Representación pobre de entidades “del mundo real”

El proceso de normalización generalmente lidia con la creación
de relaciones que no corresponden a entidades en el “mundo
real”. La fragmentación entre entidades del “mundo real”
dentro de muchas relaciones con una representación física que
refleja esta estructura, es ineficiente tratar con muchos joins
durante el procesamiento de consultas.
Semántica sobrecargada
Cuando se tiene una relación muchos a muchos se tienen que
crear tres relaciones para poder soportarla. No hay un
mecanismo para distinguir entre entidades y relaciones o para
distinguir diferentes tipos de relaciones que existen entre las
entidades.
Soporte pobre para integridad y constraints empresariales: no

todos los RDBMS manejan todos los tipos de constraints que se
necesitan por lo que se tienen que crear en las aplicaciones y
esto es un riesgo pues se pueden tener duplicaciones, una forma
de solucionarlo parcialmente es habilitar cierto tipo de
constraints como parte del DDL (Data Definition Language).
Estructura de datos homogénea: El modelo relacional asume

homogeneidad vertical y horizontal. Homogeneidad horizontal
significa que cada tupla de una relación debe estar compuesta
los mismos atributos. homogeneidad vertical significa que los
valores en una columna en particular de una relación deben
venir todas del mismo dominio (dominio: conjunto de uno o mas
atributos admisibles para uno o mas atributos). Adicionalmente
la intersección de renglones con columnas debe ser un valor
atómico.
Operaciones limitadas
El modelo relacional solo tiene un conjunto fijo de
operaciones tales como conjuntos y operaciones
relacionadas con tuplas, operaciones que son
proporcionadas en la especificación SQL. Sin embargo
SQL no permite nuevas operaciones a especificar. Otra
vez es muy restrictivo el comportamiento de este modelo
para muchos objetos del mundo real.
Difícil manejo de consultas recursivas

La atomicidad de la información significa que no se
permiten grupos repetidos en el modelo relacional. Como
resultado, es extremadamente difícil de manejar las
consultas recursivas, esto es, consultas sobre relaciones
que una relación tiene por si misma (directa o
indirectamente)
Por ejemplo, considérese la relación simplificada Staff mostrada a

continuación, la cual almacena números de empleado y su
correspondiente numero de gerente. Como encontramos todos los
gerentes que directa o indirectamente administran a los empleados
S005? Para encontrar los dos niveles de la jerarquía, utilizaremos:
staffNo managerstaffNo
staffNo managerstaffNo S005 S004
S005 S004 S004 S003

S003 S002
S004 S003
S002 S001
S003 S002
S001 NULL
S002 S001 S005 S003
S005 S002
S001 NULL
S005 S001
S004 S002
S004 S001
S003 S001
SELECT managerStaffNo
FROM Staff
WHERE staffNo = “S005”
UNION
SELECT managerStaffNo
FROM Staff
WHERE staffNo =
(SELECT managerStaffNo
FROM Staff
WHERE staffNo = “S005”)
Falta de concordancia
El SQL-92 tiene una falta de computational completeness. Esto
es cierto con la mayoría de los DMLs y DDLs para RDBMS. Para
superar este problema y mejorar flexibilidad adicional, el
estándar SQL proporciona SQL integrado para ayudar al
desarrollo complejo de aplicaciones. Sin embargo este
enfoque produce falta de concordancia pues estamos
mezclando paradigmas diferentes:
• SQL es un lenguaje declarativo que maneja renglones de
información, mientras lenguajes tales como C es un lenguaje
procedural que puede manejar solo un renglón de datos a la
vez.
• SQL y 3GL usan diferentes modelos para representar datos.
Otros problemas con RDBMS
• Las transacciones en procesamiento de negocios son
generalmente de vida corta y las primitivas de control de
concurrencia y protocolos tales como two-phase locking no
son particularmente adecuados para transacciones de larga
duración.
• Los cambios en el esquema son difíciles. Los administradores
de bases de datos deben intervenir para cambiar las
estructuras de las bases de datos y típicamente a los
programas que accesan estas estructuras. Estos son procesos
lentos e incomodos aun con las tecnologías actuales.
• RDBMS fueron diseñados basados en contenido para utilizar
acceso asociativo (esto es enunciados declarativos con
selección basados en uno o mas predicados) y son pobres
para acceso navegacional (acceso basado en movimientos
entre registros individuales)
MODELO ORIENTADO A OBJETOS
En respuesta al incremento de la complejidad de aplicaciones
de bases de datos surgieron dos modelos nuevos: el Object-
Oriented Data Model (OODM) y el Object-Relational Data
Model (ORDM), previamente definido como un Extended
Relational Data Model (ERDM). Sin embargo, a diferencia de
otros modelos la composición actual de estos modelos no esta
muy clara. La evolución representa la tercera generación de
DBMS y se ilustra en la siguiente figura.
Hay un debate entre los que proponen OODM y los que
defienden el modelo relacional, la cual se asemeja al debate
de redes/relacional de los 70s. Ambos lados están de acuerdo
en que RDBMS tradicionales son inadecuadas para cierto tipo
de aplicaciones. Sin embargo, los dos lados difieren en la mejor
solución. Los que proponen OODM reclaman que RDBMS son
satisfactorias para aplicaciones de negocio estándar, pero le
falta la capacidad de soportar mas aplicaciones complejas.
Los que defienden el modelo relacional reclaman que la
tecnología relacional es una parte necesaria de cualquier
DMBS real y que las aplicaciones complejas pueden ser
manejadas por extensiones del modelo relacional.
Hierarchical
Data Model Historia de los Data Models
Network Data
Model
Relational
Data
Model
ER Data Model
Semantic
Data
Model
Object-Relational Object-oriented
Data Model Data Model
En la actualidad el modelo de DBMS objeto-relacional es el sistema
dominante y el modelo de DBMS orientado a objetos tiene su
propio nicho de mercado.
Definición de Object-Oriented DBMS
OODM un modelo de datos (lógico) que captura la semántica de

los objetos soportada en programación orientada a objetos
OODB una colección persistente y compartible de objetos

definidos en una OODM
OODBMS el administrador de un OODB
Algunos autores mencionan los requisitos mínimos que un OODBMS

debe cumplir:
1) debe proporcionar funcionalidad de bases de datos

2) debe proporcionar identidad de objetos
3) debe proporcionar encapsulamiento
4) debe soportar objetos con estado complejo
Zudonik y Maier (1990)
Los autores argumentan que aunque la herencia es útil,
no es esencial para la definición y una OODBMS puede
existir sin tenerla, por otro lado Khoshafian y Abnous (1990)
definen OODBMS como:
1) object-orientation = abstract data types + inheritance
+ object identity;
2) OODBMS = object-orientation+database capabilities
Sin embargo otra definición de OODBMS es dada

por Parsaye et. al. (1989)
1. Un lenguaje de alto nivel con capacidades de
optimización de queries en los sistemas
subyacentes;
2. soporte para persistencia, transacciones atómicas
y control de concurrencia y recuperación;
3. soporte para almacenamiento de objetos
complejos, índices y acceso a métodos para
recuperación rápida y eficiente
4. OODBMS = object-oriented system + (1)+(2)+(3)
Algunas OODBMS actuales comerciales son:

GemStone/S de GemStone Systems Inc.
Objectivity/DB de Objectivity Inc. ObjectStore from
Progress Software Corporation, Poet ahora
FastObjects.Net de Versant Corporation, Jasmine
Object Database de Computer Associates/Fujitsu
Limited y Versant Object Database de Versant
Corporation
Con estas podemos observar que los conceptos de
modelos de datos orientado a objetos esta dibujado
desde diferentes áreas como se muestra en la
siguiente figura
ORIGEN DEL MODELO DE DATOS
ORIENTADO A OBJETOS
Sistemas de Bases de Programación Requerimientos
datos tradicionales Modelo de orientada a objetos especiales
• Persistente datos • Identidad de • Versiones
• Compartido semántico objeto
• Generalizado • Evolución
• Transacciones • Encapsulamiento del esquema
• control de • Agregación • Herencia
concurrencia • Tipos y clases
• Control de • Métodos
recuperación • Objetos
• Seguridad complejos
• Integridad • Polimorfismo
• Consultas • Extensibilidad
Modelo de datos orientado a

objetos
THE OBJECT-ORIENTED DATABASE
SYSTEM MANIFESTO
The Object-Oriented Database System Manifesto de 1989
propuso trece características obligatorias para un OODBMS.
basado en dos criterios: lo que debería ser un sistema
orientado a objetos y lo que debería ser un DBMS (Atkinson et.
al. 1989). Las reglas se resumen en la siguiente tabla:
CARACTERÍSTICAS OBLIGATORIAS EN EL OBJECT-
ORIENTED DATABASE SYSTEM MANIFESTO
Características orientadas a objetos Características DBMS
Debe soportar objetos complejos Se debe proporcionar persistencia de datos

Debe soportar identidad de objetos DBMS debe ser capaz de administrar very large
databases
Debe soportar encapsulación DBMS debe soportar usuarios concurrentes
Debe soportar tipos o clases DBMS debe ser capaz de recuperarse de fallas
de software y hardware
Los tipos o clases deben tener la DBMS debe proporcionar una manera simple
capacidad de heredar de sus de consultar información
ancestros
Debe soportar enlace dinámico
El DML debe ser computacionalmente
completo
El conjunto de datos debe ser
extensible
PERSISTENCIA EN OODBMS
DBMSs tienen la preocupación primaria con la

creación y mantenimiento de colecciones de datos
extensas y a largo plazo. Los sistemas gestores de
bases de datos modernas se caracterizan por
soportar las siguientes características:
• Un modelo de datos
• Persistencia de la información
• Compartir información
• Confiabilidad
• Escalabilidad
• Seguridad e integridad
• Distribución
En contraste a los lenguajes de programación

tradicionales que proporcionan constructores para
control procedural y para abstracción de datos y
funcional, pero falta de soporte integrado para la
mayoría de las características de bases de datos
mencionadas. Aunque cada uno es útil en su dominio
respectivo, existen un numero de aplicaciones que se han
ido incrementando que requieren funcionalidad de
ambos DBMS y lenguajes de programación. Tales
aplicaciones son caracterizadas por la necesidad de
almacenar y explotar grandes cantidades de información
compartida y estructurada. Desde 1980 se ha realizado
un esfuerzo considerable dedicado al desarrollo de
sistemas que integran los conceptos de estos dos
dominios. Sin embargo, los dos dominios tienen ligeras
diferencias en su perspectiva que tienen que considerarse
en las diferencias mencionadas.
Quizás dos de las preocupaciones mas importantes de

las perspectivas de los programadores son desempeño y
facilidad de utilización. Con DBMS tradicionales
encontramos lo siguiente:
• Es responsabilidad del programador decidir cuando leer
y actualizar objetos (registros).
• El programador tiene que escribir el código para
traducir entre el modelo de objetos de la aplicación y el
modelo de datos del DBMS (por ejemplo relaciones) las
cuales pueden ser bastante diferentes. Con un lenguaje
de programación orientado a objetos, donde un objeto
puede estar compuesto de muchos sub objetos
representados por apuntadores la traducción puede ser
particularmente compleja. Se ha confirmado que el 30%
del esfuerzo en programación y el espacio del codigo
se dedica a este tipo de mapeo.
si este proceso de mapeo puede ser eliminado o al

menos reducido, los programadores estarían libres
de esta responsabilidad, el código resultante seria
mas fácil de entender y mantener, y el desempeño
se incrementaría como resultado de esto.
• Si la responsabilidad del programador de realizar la
validación de tipos cuando un objeto es leído de la
base de datos. Por ejemplo, un programador
puede crear un objeto en un lenguaje orientado a
objetos robusto como Java y almacenado en
DBMS tradicional. Sin embargo, otra aplicación
escrita en diferente lenguaje puede modificar el
objeto, esto no garantiza que el objeto se ajuste al
tipo original.
Estas dificultades refrenan del hecho de que DBMS

tradicionales un modelo de almacenamiento de dos
niveles: el modelo de almacenamiento de la
aplicación en memoria principal o virtual y el modelo
de almacenamiento de la base de datos en disco.
como se muestra en la figura 1. En contraste, una
OODBMS da la ilusión de un modelo de
almacenamiento de un solo nivel con una
representación similar en memoria y disco, como se
ilustra en la figura 2.
FIGURA 1. MODELO DE ALMACENAMIENTO DE DOS NIVELES
PARA DBMS CONVENCIONALES (RELACIONALES)
Memoria principal o
virtual
Transformación y
validación de tipo
SQL
Almacenamiento
secundario
FIGURA 2. MODELO DE ALMACENAMIENTO DE UN SOLO NIVEL
Memoria principal o
virtual
Almacenamiento
secundario
Aunque el modelo de un solo nivel luce muy simple, la

OODBMS tiene que manejar hábilmente la representación
de los objetos en memoria y en disco para lograr esta
ilusión. Los objetos y sus relaciones entre estos, son
identificados por identificadores de objetos (OIDs por sus
siglas en inglés object identifiers)
Hay dos tipos de OIDs:
• OIDs lógicos que son independientes de la ubicación
física del objeto en disco;
• OIDs físicos que codifican su ubicación
En el primer caso, se requiere un nivel de indirección para
buscar la dirección física del objeto en disco. En ambos
casos, sin embargo, el OID es diferente en tamaño para
un apuntador estándar en memoria que necesita ser mas
lo suficientemente grande para solo direccionar toda la
memoria virtual.
Por lo tanto para lograr el rendimiento requerido, una

OODBMS debe ser capaz de convertir OIDs a apuntadores
de memoria. Esta técnica de conversión se le llama
“pointer swizzling” o object faulting y los enfoques
utilizados para implementarlo han variado desde
revisiones de residencia basadas en software a esquemas
de page faulting utilizados por software subyacente (Moss
and Eliot, 1990).
Técnicas pointer swizzling
Pointer swizzling es la acción de convertir objects
identifiers para mantener los apuntadores a la memoria y
viceversa.
El objetivo del pointer swizzling es el de optimizar el acceso
a los objetos. Si se lee un objeto del almacenamiento
secundario a una pagina cache, debe ser capaz de
localizar cualquier objeto referenciado en el
almacenamiento secundario usando su OID. Sin embargo,
una vez que los objetos referenciados han sido leídos

dentro del cache, se registra que los objetos están ahora
en memoria principal para prevenir que se lean
nuevamente del almacenamiento secundario. Un
enfoque es el de tener una tabla de búsqueda que
mapea OIDs a apuntadores en memoria principal. Se
puede implementar razonablemente bien esta tabla de
búsqueda utilizando hashing, pero esto todavía es lento
comparado con el pointer dereference, particularmente si
el objeto esta ya en memoria. Sin embargo pointer
swizzling intenta proporcionar una estrategia mas eficiente
para almacenar los apuntadores en memoria principal en
lugar de referencias a OIDs y viceversa cuando el objeto
ha sido escrito de regreso a disco.
No swizzling
La implementación mas fácil de faulting objects dentro y
fuera de memoria es no hacer ningún swizzling. En este
caso, los objetos son faulted dentro de la memoria por el
administrador de objetos adyacente y un handle es
pasado de regreso a la aplicación que contiene los OIDs
de los objetos. El OID es utilizado cada vez que el objeto
es accesado. Este requiere que el sistema mantenga
algún tipo de la tabla de búsqueda así que el apuntador
en memoria virtual del objeto puede ser localizado y
entonces utilizado para accesar al objeto. Como la
búsqueda es requerida para cada acceso de objetos,
este enfoque puede ser ineficiente en el caso de que
algún objeto sea accesado repetidas veces.
La figura 3 muestra el contenido de la tabla de

búsqueda, algunas veces llamada Resident Object
Table (ROT), después de que cuatro objetos han sido
leídos del almacenamiento secundario, ahora se
puede accesar el objeto Staff con el identificador del
objeto OID5 del objeto Branch OID1; una búsqueda
de ROT puede indicar que el objeto no esta en
memoria principal y se tiene que leer el objeto del
almacenamiento secundario y entra este en la
dirección de memoria en la tabla ROT. Por otro lado,
si trata de accesar el objeto Staff con el OID4 desde
el objeto Branch la búsqueda en ROT indicará que el
objeto esta ya en memoria principal y proporciona la
dirección.
FIGURA 3 RESIDENT OBJECT TABLE REFERENCIANDO
CUATRO OBJETOS EN MEMORIA PRINCIPAL
Branch: OID1 Resident Object Table PropertyforRent: OID2

OID memory address propertyNo: PG4
branchNo:B003
street: 163 Main St street: 6 Lawrence St
1 ......... type: Flat
city: Glasgow 2 ........ rooms: 3
postcode: G11 9QX 3 ......... rent: 350
staff: {OID4, OID5, ...} 4 ......... staff: OID4
property: {OID2, OID3,...} branch: OID1
manager: OID6 ......
Staff: OID4 PropertyforRent: OID3

staffNo: SG14 propertyNo: PG18
fname: David street: 5 Novar Dr
lname: Ford type: Flat
position: Supervisor rooms: 4
sex: M rent: 450
salary: 18000 staff: OID4
branch: OID1 branch: OID1
Los lenguajes de programación orientados a objetos ya

poseen un concepto de objeto, un sistema de tipos para
definir tipos de objetos y constructores para crearlos. Sin
embargo, estos objetos son transitorios; desaparecen en
cuanto finaliza el programa, igual que ocurre con las
variables de los programas en C o C++. Si se desea
transformar uno de estos lenguajes en un lenguaje de
programación para bases de datos, el primer paso
consiste en proporcionar una manera de hacer
persistentes a los objetos, se han propuesto varios
enfoques:
• Persistencia por clases. El enfoque mas sencillo, pero
menos conveniente, consiste en declarar que una clase
es persistente. Todos los objetos de la clase son, por lo
tanto, persistentes de manera predeterminada. Todos los
objetos de la clase no persistentes son transitorios
Este enfoque no es flexible, dado que suele resultar

útil disponer en una misma clase tanto objetos transitorios
y persistentes. Muchos OODBMS interpretan la declaración
de que una clase es persistente como si se afirmara que
los objetos de la clase pueden hacerse persistentes, en
vez de que todos los objetos de la clase son persistentes.
Estas clases se pueden denominar con mas propiedad
clases “que pueden ser persistentes”.
• Persistencia por creación. En este enfoque se introduce
una sintaxis nueva para crear los objetos persistentes
mediante la extensión de la sintaxis para la creación de
los objetos transitorios. Por lo tanto, los objetos son
persistentes o transitorios en función de la forma de
crearlos. Varios OODBMS siguen este enfoque.
• Persistencia por marcas. Una variante del enfoque

anterior es marcar los objetos como persistentes después
de haberlos creado. Todos los objetos se crean como
transitorios pero, si un objeto tiene que persistir mas allá
de la ejecución del programa, hay que marcarlo como
persistente de manera explicita antes de que este
concluya. Este enfoque, a diferencia del anterior,
pospone la decisión sobre la persistencia o
transitoriedad hasta después de la creación del objeto.
• Persistencia por alcance. Uno o varios objetos se
declaran objetos persistentes (objetos raíz) de manera
explicita. Todos los demás objetos serán persistentes si y
solo si se pueden alcanzar desde algún objeto raíz
mediante una secuencia de una o varias referencias.
Por tanto, todos los objetos a los que se haga

referencia desde (es decir, cuyos OID se guardan en)
los objetos persistentes raíz serán persistentes. Pero
también lo serán todos los objetos a los que haga
referencia desde ellos, y los objetos a los que estos
últimos hagan referencia serán persistentes, etc.
Una ventaja de este esquema es que resulta sencillo
hacer que sean persistentes estructuras de datos
completas con solo declarar como persistente su raíz.
Sin embargo, el DBMS sufre la carga de tener que
seguir las cadenas de referencias para detectar los
objetos que son persistentes y eso puede resultar
costoso.
Identidad de los objetos y apuntadores

En los lenguajes de programación orientados a objetos que no se han
extendido para tratar la persistencia, cuando se crea un objeto el
sistema devuelve un OID transitorio. Los OID transitorios solo son validos
mientras se ejecuta el programa que los ha creado; después de que
concluya ese programa, el objeto se borra y el identificador pierde su
sentido. Cuando se crea un objeto persistente se le asigna un OID
persistente.
El concepto de identidad de los objetos tiene una relación interesante
con apuntadores de los lenguajes de programación. Una manera
sencilla de conseguir una identidad intrínseca es usar los apuntadores a
las ubicaciones físicas del almacenamiento. En concreto en muchos
lenguajes orientados a objetos como C++, los OID son en realidad
apuntadores internos en memoria.
Sin embargo, la asociación de los objetos con ubicaciones físicas de
almacenamiento puede variar con el tiempo. Hay varios grados de
permanencia de las identidades.
• Dentro de los procedimientos. La identidad solo persiste

durante la ejecución de un único procedimiento. Un
ejemplo de identidad dentro de los programas son las
variables locales de los procedimientos.
• Dentro de los programas. La identidad solo persiste durante
la ejecución de un único programa o de una única
consulta. Un ejemplo de identidad dentro de los
programas son las variables globales de los lenguajes de
programación. Los punteros de la memoria principal o de
la memoria virtual solo ofrecen identidad dentro de los
programas.
• Entre programas. La identidad persiste de una ejecución
del programa a otra. Los punteros a los datos del sistema
de archivos del disco ofrecen identidad entre programas,
pero pueden cambiar si se modifica la manera en que los
datos se guardan en el sistema de archivos.
• Persistente. La identidad no solo persiste entre las

ejecuciones del programa sino también entre
reorganizaciones estructurales de los datos. En la forma
persistente de identidad necesaria para los sistemas
orientados a objetos.
En las extensiones persistentes de los lenguajes como C++, los
OID persistentes se implementan como “punteros
persistentes”. Un puntero persistente es un tipo de puntero
que, a diferencia de los punteros internos de la memoria,
sigue siendo valido después del final de la ejecución del
programa y después de algunas modalidades de
reorganización de los datos. Los programadores pueden usar
los punteros persistentes del mismo modo que usan los
punteros internos de la memoria en los lenguajes de
programación. Conceptualmente los punteros persistentes se
pueden considerar como punteros a objetos de la base de
datos.
Almacenamiento y acceso a los objetos persistentes.

¿Que significa guardar un objeto en una base de
datos? Evidentemente, hay que guardar por separado
la parte de datos de cada objeto. Lógicamente, el
código que implementa los métodos de las clases debe
guardarse en la base de datos como parte de su
esquema, junto con las definiciones de tipos de las
clases. Sin embargo, muchas implementaciones se
limitan a guardar el código en archivos externos a la
base de datos para evitar tener que integrar el software
del sistema, como los compiladores, con el sistema de
bases de datos.
Hay varias maneras de hallar objetos de la base de datos. Una manera es

dar nombres a los objetos, igual que se hace con los archivos. Este
enfoque funciona con un numero de objetos relativamente pequeño,
pero no resulta practico para millones de objetos. Una segunda manera es
exponer los OID o los punteros persistentes a los objetos, que pueden
guardarse en el exterior. A diferencia de los nombres, los punteros no
tienen porque ser fáciles de recordar y pueden ser, incluso, punteros físicos
internos de la base de datos.
Una tercera manera es guardar conjuntos de objetos y permitir que los
programas iteren sobre ellos para buscar los objetos deseados. Los
conjuntos de objetos pueden a su vez modelarse como objetos de un tipo
conjunto. Entre los tipos de conjuntos están los conjuntos, los
multiconjuntos (es decir, conjuntos con varias apariciones posibles de un
mismo valor), las listas, etc. Un caso especial de conjunto son las
extensiones de clases, que son el conjunto de todos los objetos
pertenecientes a una clase.
Si hay una extensión de clase para una clase dada, siempre que se
crea un objeto de la clase ese objeto se inserta en la extensión de
la clase de manera automática; y siempre que se borra un objeto,
este se elimina de la extensión de la clase. Las extensiones de
clases permiten que las clases se traten como relaciones en el
sentido de que es posible examinar todos los objetos de una clase,
igual que se pueden examinar todas las tuplas de una relación.
La mayor parte de OODBMS soportan las tres maneras de acceso
a los objetos persistentes. Dan identificadores a todos los objetos.
Generalmente solo dan nombre a las extensiones de las clases y a
otros objetos del tipo conjunto y, quizás, a otros objetos
seleccionados, pero no a la mayor parte de los objetos. Las
extensiones de las clases suelen conservarse para todas las clases
que puedan tener objetos persistentes pero, en muchas de las
implementaciones, las extensiones de las clases solo contienen los
objetos persistentes de cada clase.
TIPOS DE DATOS COMPLEJOS
Las aplicaciones de bases de datos tradicionales consisten en
tareas de procesamiento de datos, tales como aplicaciones
bancarias y gestión de nominas. Dichas aplicaciones presentan
conceptualmente tipos de datos simples. Los elementos básicos
son registros bastante pequeños y cuyos campos son atómicos, es
decir no contienen estructuras de datos adicionales.
En los últimos años, ha crecido la demanda de formas de abordar
tipos de datos mas complejos. Considérese, por ejemplo, las
direcciones. Mientras que una dirección completa se puede
considerar como un elemento de datos atómico del tipo cadena
de caracteres, esa forma de verlo esconde detalles como la calle,
población, estado y código postal, que pueden ser interesantes
para la consulta. Por otra parte si una dirección se representa
dividiéndola en sus componentes (calle, población, estado,
código postal) la escritura de las consultas será mas complicada,
pues tendrían que mencionar cada campo. Una alternativa mejor
es permitir tipos de datos estructurados, que admiten el tipo
dirección con las subpartes calle, población, estado y codigo
postal.
En vez de considerar la base de datos como un conjunto de

registros, los usuarios de ciertas aplicaciones la ven como un
conjunto de objetos (o de entidades). Puede que cada
objeto necesite varios registros para su representación. Una
interface sencilla y fácil de usar necesita una
correspondencia de uno a uno entre el concepto intuitivo
de objeto del usuario y el concepto de elemento de datos
de la base de datos.
Considérese, por ejemplo, una aplicación para una
biblioteca y supóngase que se desea almacenar la
información siguiente para cada libro:
• Titulo de libro
• Lista de autores
• Editor
• Conjunto de palabras clave
Es evidente que, si se define una relación para esta
información varios dominios no son atómicos.
• Autores. Cada libro puede tener una lista de autores, que
se pueden representar como array. Pese a todo, puede
que se desee averiguar todos los libros de los que es autor
“Santos”. Por lo tanto, lo que interesa es una subparte del
elemento del dominio “autores”.
• Palabras clave. Si se almacena un conjunto de palabras
clave incluyan uno o mas términos dados. Por tanto se
considera el dominio del conjunto de palabras clave como
no atómico.
• Editor. A diferencia de palabras clave y autores, editor no
tiene un dominio que se evalué en forma de conjunto. No
obstante, se puede considerar que editor consta de los
subcampos nombre y sucursal. Este punto de vista hace
que el dominio de editor no sea atómico.
La figura 4 muestra una relación de ejemplo libros.

Por simplificar se da por supuesto que el titulo del libro lo
identifica de manera univoca (como si fuera el numero de
ISBN en el mundo real). Se puede representar, entonces la
misma información usando el esquema siguiente:
• autores(titulo, autor, posición)
• palabras_clave(titulo, palabra_clave)
• libros4(titulo, nombre_editor, sucursal_editor)
Aunque la base de datos de libros de ejemplo puede
expresarse de manera adecuada sin necesidad de usar
relaciones anidadas, su uso lleva a un modelo mas fácil de
aprender.
La posibilidad de usar tipos de datos complejos como los
conjuntos y los arrays puede resultar útil en muchas
aplicaciones.
FIGURA 4. RELACIÓN DE LIBROS
titulo array_autores editor conjunto_palabras_clave
(nombre. sucursal)
Compiladores [Gomez, Santos] (McGraw-Hill, Nueva York) {análisis sintáctico, análisis}

Redes [Santos, Escudero] (Oxford, Londres) {Internet, Web}
TIPOS ESTRUCTURADOS Y HERENCIA
SQL
Antes de SQL:1999 el sistema de tipos SQL consistía en un conjunto
bastante sencillo de tipos predefinidos. SQL:1999 añadió un sistema
de tipos extenso a SQL, lo que permite los tipos estructurados y la
herencia de tipos.
Tipos estructurados
Los tipos estructurados permiten representar directamente los
atributos compuestos de los diagramas E-R. Por ejemplo, se puede
definir el siguiente tipo estructurado para representar el atributo
compuesto nombre con los atributos componentes nombredepila
y apellidos:
CREATE TYPE Nombre AS

(nombredepila VARCHAR(20),
apellidos VARCHAR(20))
FINAL
SQL
De manera parecida, el tipo estructurado siguiente puede
usarse para representar el atributo compuesto dirección:
CREATE TYPE Dirección AS

(calle VARCHAR(20),
ciudad VARCHAR (20),
codigopostal VARCHAR (9))
NOT FINAL
En SQL estos tipos se denominan tipos definidos por el
usuario. Las especificación FINAL indica que no se pueden
crear subtipos de Nombre, mientras que NOT FINAL indica
que se pueden crear subtipos de Dirección.
SQL
Ahora se pueden usar estos tipos para crear atributos compuestos en
las relaciones, solo hay que declarar que un atributo es de uno de
esos tipos. Por ejemplo, se puede crear la tabla cliente de la siguiente
manera:
CREATE TABLE cliente

(nom Nombre,
dir Direccion,
fechadenacimiento DATE)
Se puede tener acceso a los componentes de los atributos

compuestos usando la notación “punto”; por ejemplo,
nom.nombredepila devuelve el componente nombre de pila del
atributo nombre. El acceso al atributo nombre devolvería un valor del
tipo estructurado Nombre.
También se puede crear una tabla cuyas filas sean de un tipo definido
por el usuario. Por ejemplo, se puede definir el tipo TipoCliente y crear
una tabla cliente de la siguiente manera:
SQL
CREATE TYPE TipoCliente AS
(nomb Nombre,
direc Direccion,
NOT FINAL
CREATE TABLE cliente OF TipoCliente
Una manera alternativa de definir los atributos

compuestos en SQL es usar tipos de fila sin nombre. Por
ejemplo, la relación que representa la información del
cliente se podrá haber creado usando tipos de fila de
la siguiente manera:
SQL
CREATE TABLE cliente
(nom ROW (nombredepila VARCHAR(20),
apellidos VARCHAR (20)),
dir ROW (calle VARCHAR (20),
ciudad VARCHAR (20),
codigopostal VARCHAR(9)),
Esta definición es equivalente a la anterior definición de

tabla, salvo que los atributos nombre y dirección tienen tipos
sin nombres y las filas de la tabla también tienen un tipo sin
nombre.
La consulta siguiente ilustra la manera de tener acceso a los
atributos componentes de los atributos compuestos. La
consulta busca el apellido y la ciudad de cada cliente.
SQL
SELECT nom.apellidos, dir.ciudad
FROM cliente
Sobre los tipos estructurados se pueden definir métodos. Los

métodos se declaran como parte de la definición de los
tipos estructurados.
CREATE TYPE TipoCliente AS (

nom1 Nombre,
dir1 Direccion,
fechaDeNacimiento DATE)
NOT FINAL
METHOD edadAFecha(aFecha DATE)
RETURNS INTERVAL YEAR
SQL
El cuerpo del método se crea por separado:
CREATE INSTANCE METHOD edadAFecha (aFecha DATE)

RETURNS INTERVAL YEAR
FOR TipoCliente
BEGIN
RETURN aFecha -self.fechaDeNacimiento
END
Téngase en cuenta que la clausula FOR indica el tipo al que se

aplica el método, mientras que la palabra clave INSTANCE indica
que el método se ejecuta sobre un ejemplar del tipo Cliente sobre
el que se invoca el método. El cuerpo del método puede contener
instrucciones procedimentales. Los métodos pueden actualizar los
atributos del ejemplar sobre el que se ejecutan.
SQL
Los métodos se pueden invocar sobre los ejemplares de los tipos. Si
se hubiera creado la tabla cliente del tipo TipoCliente, se podría
invocar el método edadAFecha() como se ilustra a continuación,
para averiguar la edad de cada cliente:
SELECT nombre.apellidos, edadAFecha(CURRENT_DATE)

FROM cliente
En SQL:1999 se usan funciones constructoras para crear valores de

los tipos estructurados. Las funciones con el mismo nombre que un
tipo estructurado son funciones constructoras de ese tipo
estructurado. Por ejemplo, se puede declarar una función
constructora para el tipo Nombre de esta manera:
SQL
CREATE FUNCTION Nombre(nombredepila VARCHAR (20),
apellidos VARCHAR(20))
RETURNS Nombre
BEGIN
SET SELF.nombredepila=nombredepila;
SET SELF.apellidos= apellidos;
END
Se puede usar NEW Nombre(‘Martin’, ‘Gomez’) para crear un valor
del tipo Nombre.
Se puede crear un valor de fila haciendo una relación de sus
atributos entre paréntesis. Por ejemplo, si se declara el atributo
nombre, como tipo de fila con los componentes nombredepila y
apellidos, se puede crear para él este valor:
(‘Ted’,’Codd’)
SQL
Sin necesidad de función constructora.
De manera predeterminada, cada tipo estructurado tiene una
función constructora sin argumentos, que configura los atributos
con sus valores predeterminados. Cualquier otra función
constructora hay que crearla de manera explicita. Puede haber
mas de una función constructora para el mismo tipo estructurado;
aunque tengan el mismo nombre, deben poder distinguirse por el
numero y tipo de sus argumentos.
La instrucción siguiente ilustra la manera de crear una nueva tupla
de la relación Cliente. Se da por supuesto que se ha definido una
función constructora para Direccion, igual que la función
constructora que se definió para Nombre:
SQL
INSERT INTO Cliente
VALUES (
NEW Nombre(´Martin’, ‘Gomez’),
NEW Direccion(‘Calle Mayor, 20’, ‘Madrid’, ‘28045’),
DATE ‘22-08-1960’)
HERENCIA DE TIPOS
Supóngase que se tiene la siguiente definición de tipo para las
personas:
CREATE TYPE Persona
(nombre VARCHAR(20),
direccion VARCHAR(20)
Puede que se desee almacenar en la base de datos información

adicional sobre las personas que son estudiantes y sobre las que
son profesores. Dado que los estudiantes y los profesores también
son personas, se puede usar la herencia para definir en SQL los
tipos estudiantes y profesor:
HERENCIA DE TIPOS
CREATE TYPE Estudiante

UNDER Persona
(grado VARCHAR(20),
materia VARCHAR (20))
CREATE TYPE Profesor
UNDER Persona
(sueldo INTEGER,
materia VARCHAR(20))
Tanto Estudiante como Profesor heredan los atributos de Persona –

es decir, nombre y direccion. Se dice que Estudiante y Profesor son
subtipos de Persona y Persona es un supertipo de Estudiante y
Profesor.
HERENCIA DE TIPOS
Los métodos de los tipos estructurados se heredan por sus subtipos,
igual que los atributos. Sin embargo, cada subtipo puede redefinir
el efecto de los métodos volviendo a declararlos, usando
overriding method en lugar de method en la declaración del
método.
Supóngase que se desea almacenar información sobre los
profesores ayudantes, que son a la vez estudiantes y profesores,
quizás incluso en materias diferentes. Esto se puede hacer si el
sistema de tipos soporta herencia múltiple por la que se pueden
declarar los tipos como subtipos de varios tipos. Téngase en cuenta
que la norma SQL (hasta las versiones SQL:1999 y SQL 2003 al
menos) no soporta la herencia múltiple, aunque puede que si que
la soporten versiones futuras.
Por ejemplo, si el sistema de tipos soporta la herencia múltiple, se
puede definir el tipo para los profesores ayudantes de la siguiente
manera:
HERENCIA DE TIPOS
CREATE TYPE Asesor

UNDER Estudiante, Profesor
Asesor heredará todos los atributos de Estudiante y de Profesor. No

obstante, hay un problema, ya que los atributos nombre y materia
están presentes tanto en Estudiante como en Profesor.
Los atributos nombre y direccion se heredan realmente de una
fuente común, Persona. Por lo tanto, no hay ningún conflicto
causado por heredarlos de Estudiante y Profesor. Sin embargo el
atributo materia se define por separado en Estudiante y Profesor.
De hecho, cada asesor puede ser estudiante en una materia y
profesor en otra. Para evitar conflictos entre las dos apariciones de
materia, y se puede redefinir usando una clausula AS:
HERENCIA DE TIPOS
CREATE TYPE Asesor
UNDER Estudiante WITH (materia AS materia_estudiante),
Profesor WITH (materia AS materia_profesor)
Hay que tener en cuenta nuevamente que SQL solo soporta

herencia simple.
En SQL como en la mayor parte del resto de los lenguajes, el valor
de un tipo estructurado debe tener exactamente un “tipo mas
concreto”. Es decir, cada valor debe asociarse, al crearlo, con un
tipo concreto, denominado su tipo mas concreto. Mediante la
herencia también se asocia con cada uno de los supertipos de su
tipo mas concretos. Por ejemplo, supóngase que una entidad es
tanto del tipo Persona como del tipo Estudiante. Entonces, el tipo
mas concreto de la entidad es Estudiante, ya que Estudiante es un
subtipo de Persona. Sin embargo, una entidad no puede ser de los
HERENCIA DE TIPOS
tipos Estudiante y Profesor, a menos que tenga un tipo, como

Asesor, que sea subtipo de Profesor y de Estudiante (lo cual no es
posible en SQL ya que SQL no soporta herencia múltiple).
Herencia de Tablas
Las subtablas de SQL se corresponden con el concepto de
especialización/generalización de E-R. Por ejemplo, supóngase
que se define la tabla personas de la manera siguiente:
CREATE TABLE personas OF Persona
A continuación se pueden definir las tablas estudiantes y

profesores como subtablas de personas, de la siguiente manera:
HERENCIA DE TABLAS
CREATE TABLE estudiantes OF Estudiante
UNDER personas
CREATE TABLE profesores OF Profesor

UNDER personas
Los tipos de las subtablas deben ser subtipos del tipo de la tabla
padre. Por tanto, todos los atributos presentes en personas también
están presentes en las subtablas.
Además, cuando se declaran estudiantes y profesores como
subtablas de personas, todas las tuplas presentes en estudiantes o
profesores pasan a estar también presentes de manera implícita en
personas. Por lo tanto, si una consulta usa la tabla personas, no solo
encuentra tuplas directamente insertadas en esta tabla, sino también
tuplas insertadas en sus subtablas, es decir, estudiantes y profesores.
No obstante, esa consulta solo puede tener acceso a los atributos que
están presentes en personas.
HERENCIA DE TABLAS
SQL permite hallar tuplas que se encuentran en personas pero no

en sus subtablas usando en las consultas “ONLY personas” en lugar
de personas. La palabra clave ONLY también puede usarse en las
sentencias DELETE y UPDATE. Sin la palabra clave ONLY, la
instrucción DELETE aplicada a una supertabla, como personas,
también borra las tuplas que se insertaron originalmente en las
subtablas (como estudiantes); por ejemplo, la instrucción:
DELETE FROM personas WHERE P
borrará todas las tuplas de la tabla personas, así como de sus

subtablas estudiantes y profesores., que satisfagan la condición. Si
se agrega la palabra clave ONLY a la instrucción anterior, las tuplas
que se insertaron en las subtablas no se ven afectadas, aunque
satisfagan las condiciones de la clausula WHERE. Las consultas
HERENCIA DE TABLAS
posteriores a la supertabla seguirán encontrando esas tuplas.

Teóricamente, la herencia múltiple es posible con las tablas, igual
que con los tipos. Por ejemplo, se puede crear una tabla del tipo
asesor:
CREATE TABLE asesores
OF asesor
UNDER estudiantes, profesores
Como consecuencia de la declaración, todas las tuplas presentes

en la tabla asesores también se hallaran presentes de manera
implícita en las tablas profesores y estudiantes y a su vez, en la
tabla personas.
TIPOS ARRAY Y MULTICONJUNTO EN
SQL
SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos
array se añadieron en SQL:1999, mientras que los tipos
multiconjunto se agregaron en SQL:2003. Recuérdese que un
multiconjunto es un conjunto no ordenado, en el que cada
elemento puede aparecer varias veces. Los multiconjuntos son
como los conjuntos, salvo que los conjuntos permiten que cada
elemento aparezca, como mucho, una vez.
Supóngase que se desea registrar información sobre libros, incluido
un conjunto de palabras clave para cada libro. Supóngase
también que se deseara almacenar el nombre de los autores de
un libro en forma de array; a diferencia de los elementos de los
multiconjuntos, los elementos de los arrays están ordenados, de
modo que se puede distinguir el primer autor del segundo, etc. El
ejemplo siguiente ilustra la manera en que se pueden definir en
SQL estos atributos valorados como arrays y multiconjuntos.
TIPOS ARRAY Y MULTICONJUNTO EN
SQL
CREATE TYPE Editor AS
(nombre VARCHAR(20),
sucursal VARCHAR(20))
CREATE TYPE Libro AS
(titulo VARCHAR(20),
array_autores VARCHAR(20) ARRAY [10],
fecha_publicacion DATE,
editor1 Editor,
conjunto_palabras_clave VARCHAR(20) MULTISET)
CREATE TABLE Libros OF Libro
En general, los atributos multivalorados de los esquemas E-R se

pueden asignar en SQL a atributos valorados como multiconjuntos;
si el orden es importante, se pueden usar los arrays de SQL en lugar
de los multiconjuntos.
CREACIÓN Y ACCESO A LOS VALORES
DE LOS CONJUNTOS
En SQL:1999 se puede crear un array de valores de esta manera:
ARRAY[‘Silberschatz’, ’Korth’, ’Sudarshan’]
De manera parecida, se puede crear un multiconjunto de

palabras clave como sigue:
MULTISET[‘computadora’, ’base de datos’, ’SQL’]
Por lo tanto, se puede crear un tupla del tipo definido por la

relación libros como:
(‘Compiladores’, ARRAY[‘Gómez’, ‘Santos’], NEW Editor(‘McGraw-
Hill’, ‘Nueva York’), MULTISET[‘análisis sintáctico’, ’análisis’])
CREACIÓN Y ACCESO A LOS VALORES
DE LOS CONJUNTOS
En este ejemplo se ha creado un valor para el atributo Editor
mediante la invocación a una función constructora para Editor
con los argumentos correspondientes. Téngase en cuenta que esta
constructora para Editor se debe crear de manera explicita y no se
halla presente de manera predeterminada; se puede declarar
como la constructora para Nombre, que ya se ha visto antes.
Si se desea insertar la tupla anterior en la relación libros, se puede
ejecutar la instrucción:
INSERT INTO libros

VALUES
(‘Compiladores’, ARRAY[‘Gómez’, ‘Santos’], NEW Editor(‘McGraw-
Hill’, ‘Nueva York’), MULTISET[‘análisis sintáctico’, ’análisis’])
Se puede tener acceso a los elementos del array o actualizarlos
especificando el índice del array, por ejemplo, array_autores[1].
CONSULTA DE LOS ATRIBUTOS
VALORADOS COMO CONJUNTOS
Ahora se considerará la forma de manejar los atributos que se valoran
como conjuntos. Las expresiones que se valoran como conjuntos
pueden aparecer en cualquier parte en la que pueda aparecer el
nombre de una relación, como las clausulas FROM, como se ilustran los
siguientes párrafos.
Si se desea averiguar todos los libros que tienen las palabras “base de
datos” entre sus palabras clave se puede usar la siguiente consulta:
SELECT titulo FROM libros

WHERE ‘base de datos’ IN (UNNEST(conjunto_palabras_clave)
Obsérvese que se ha utilizado UNNEST(conjunto_palabras_clave) en

una posición en la que SQL sin las relaciones anidadas habrá exigido
una subexpresión SELECT-FROM-WHERE.
Si se sabe que un libro concreto tiene tres autores, se puede escribir:
SELECT array_autores[1], array_autores[2], array_Autores[3]
FROM libros
WHERE titulo = ‘Fundamentos de bases de datos’
Ahora supóngase que se desea una relación que contenga

parejas de la forma “titulo, nombre_autor” para cada libro y para
cada uno de sus autores. Se puede usar esta consulta:
SELECT L.titulo, A.autores

FROM libros AS L, UNNEST(L.array_autores) AS A(autores)
Dado que el atributo array_autores de libros es un campo que se

valora como conjunto, UNNEST(L.array_autores) puede usarse en
una clausula FROM en la que se espere una relación.
Al desanidar un array la consulta anterior pierde información sobre
el orden de los elementos del array. Se puede usar la clausula
UNNEST WITH ORDINALITY para obtener esta información, como se
ilustra en la siguiente consulta. Esta consulta se puede usar para
generar la relación autores, que se ha visto anteriormente a partir
de la relación libros.
SELECT titulo, A.autores, A.posicion

FROM libros AS L,
UNNEST(L.array_autores) WITH ORDINALITY AS
A(autores, posicion)
La clausula WITH ORDINALITY genera un atributo adicional que

registra la posición del elemento en el array.
ANIDAMIENTO Y DESANIDAMIENTO
La transformación de una relación anidada en una forma con

menos atributos de tipo relación (o sin ellos) se denomina
desanidamiento. La relación libros tiene dos atributos,
array_autores y conjunto_palabras_claves, que son conjuntos, y
otros dos, titulo y editor, que no lo son. Supóngase que se desea
convertir la relación en una sola relación plana, sin relaciones
anidadas ni tipos estructurados como atributos. Se puede usar la
siguiente consulta para llevar a cabo la tarea:
SELECT titulo, A.autor, editor.nombre AS nombre_editor,

editor.sucursal AS sucursal_editor, P.palabras_clave
FROM libros as L, UNNEST(L.array_autores) AS A(autores),
UNNEST(L.conjunto_palabras_clave) AS P(palabras_clave)
La variable L de la clausula FROM se declara para que tome

valores de libros. La variable A se declara para que tome valores
de los autores de array_autores para el libro L y P se declara para
que tome valores de las palabras clave del
conjunto_palabras_clave del libro L. La siguiente figura 4 muestra
un ejemplo de la relación libros y la figura 5 muestra la relación
denominada libros_plana, que es el resultado de la consulta
anterior.
Figura 4. Relación de libros
titulo array_autores editor conjunto_palabras_clave
(nombre. sucursal)
Compiladores [Gomez, Santos] (McGraw-Hill, Nueva York) {análisis sintáctico, análisis}

Redes [Santos, Escudero] (Oxford, Londres) {Internet, Web}
FIGURA 5. LIBROS_PLANA: RESULTADO DEL DESANIDAMIENTO
DE LOS ATRIBUTOS ARRAY_AUTORES Y
CONJUNTO_PALABRAS_CLAVE DE LA RELACIÓN LIBROS
titulo autor nombre_editor sucursal_editor conjunto_palabras_clave
Compiladores Gómez McGraw-Hill Nueva York análisis sintáctico
Compiladores Santos McGraw-Hill Nueva York análisis sintáctico
Compiladores Gómez McGraw-Hill Nueva York análisis
Compiladores Santos McGraw-Hill Nueva York análisis
Redes Santos Oxford Londres Internet

Redes Escudero Oxford Londres Internet
Redes Santos Oxford Londres Web
Redes Escudero Oxford Londres Web

El proceso inverso de transformar una relación en 1FN en una relación

anidada se denomina anidamiento. El anidamiento puede realizarse
mediante una extensión de la agrupación SQL. En el uso normal de la
agrupación en SQL se crea (lógicamente) una relación multiconjunto
temporal para cada grupo y se aplica una función de agregación a
la relación temporal para obtener un valor único (atómico). La función
COLLECT devuelve el multiconjunto de valores; en lugar de crear un
solo valor se puede crear una relación anidada. Supóngase que se
tiene una relación en 1FN libros_plana, tal y como se muestra en la
figura 5. La consulta siguiente anida la relación en el atributo
palabras_clave:
SELECT titulo, autores, Editor(nombre_editor,sucursal_editor) AS Editor

COLLECT(palabras_clave) AS conjunto_palabras_clave
FROM libros_plana
GROUP BY titulo, editor
El resultado de la consulta a la relación libros_plana de la figura 5

aparece en la figura 6.
Si se desea anidar también el atributo autores en un multiconjunto se
puede usar la consulta:
SELECT titulo, COLLECT(autores) AS conjunto_autores,

Editor(nombre_editor,sucursal_editor) AS Editor
COLLECT(palabras_clave) AS conjunto_palabras_clave
FROM libros_plana
Otro enfoque de la creación de relaciones anidadas es usar

subconsultas en la clausula SELECT. Una ventaja del enfoque de las
subconsultas es que se puede usar de manera opcional en la
subconsulta una clausula ORDER BY para generar los resultados en el
orden deseado. Lo que puede aprovecharse para crear un array.
La siguiente consulta ilustra este enfoque; las palabras clave ARRAY

y MULTISET especifican que se van a crear un array y un
multiconjunto (respectivamente) a partir del resultado de las
subconsultas
SELECT titulo,
ARRAY(SELECT autores FROM autores AS A WHERE A.titulo=L.titulo
ORDER BY a.posicion) AS array_autores,
Editor(nombre_editor, sucursal_editor) AS Editor
MULTISET(SELECT palabra_clave FROM palabras_clave AS P
WHERE P.titulo=L.titulo) AS conjunto_palabras_clave
FROM libros_plana AS L
FIGURA 6. UNA VERSIÓN PARCIALMENTE ANIDADA DE LA
RELACIÓN LIBROS_PLANA
titulo autor editor conjunto_palabras_clave

(nombre_editor,
sucursal_editor)
Compiladores Gómez (McGraw-Hill, Nueva York) (análisis sintáctico, análisis )
Compiladores Santos (McGraw-Hill, Nueva York) (análisis sintáctico, análisis )
Redes Santos (Oxford, Londres) (Internet, Web)
Redes Escudero Oxford (Internet, Web)
IMPLEMENTACIÓN DE LAS
CARACTERÍSTICAS OBJETO-RELACIONAL
Los sistemas de bases de datos relacionales orientadas a
objetos son básicamente extensiones de los sistemas de
bases de datos relacionales ya existentes como
habíamos mencionado anteriormente. Las
modificaciones resaltan claramente necesarias en
muchos niveles del sistema de base de datos. Sin
embargo, para minimizar las modificaciones en el
código del sistema de almacenamiento
(almacenamiento de relaciones, índices, etc.) los tipos
de datos complejos soportados por los sistemas
relacionales orientados a objetos se pueden traducir al
sistema de tipos mas sencillo de las bases de datos
relacionales.
Para comprender la manera de hacer esta traducción,
solo hace falta mirar al modo en que algunas
características del modelo Entidad-Relación (E-R) se
traducen en relaciones. Por ejemplo los atributos
multivalorados del modelo E-R se corresponden con los
atributos valorados como multiconjuntos del modelo
relacional orientado a objetos. Los atributos compuestos
se corresponden grosso modo con los tipos
estructurados. Las jerarquías ES del modelo E-R se
corresponden con la herencia de tablas del modelo
relacional orientado a objetos.
HERENCIA DE ATRIBUTOS
Una propiedad crucial de las entidades de nivel superior e inferior
creadas mediante la especialización y generalización es la herencia
de atributos. Se dice que los atributos de los conjuntos de entidades
de nivel superior son heredados por los conjuntos de entidades de
nivel inferior. Por ejemplo, cliente y empleado heredan los atributos
de persona: Así, cliente se describe mediante sus atributos nombre,
calle y ciudad y adicionalmente, por el atributo id_cliente;
empleado se describe mediante sus atributos nombre, calle y
ciudad y, adicionalmente, por los atributos id_empleado y sueldo.
Los conjuntos de entidades de nivel inferior (o subclases) también
heredan la participación en los conjuntos de relaciones en los que
participa su entidad de nivel superior (o superclase). Los conjuntos
de entidades oficial_cajero y secretaria pueden participar en el
conjunto de relaciones trabaja_para ya que la superclase
empleado participa en la relación trabaja_para. La herencia de los
atributos se aplica a todas las capas de conjuntos de entidades de
nivel inferior. Los conjuntos de entidades anteriores pueden
participar en cualquier relación en las que participe el conjunto de
entidades persona.
HERENCIA DE ATRIBUTOS
En las jerarquías un conjunto de entidades dado solo puede

estar implicado como conjunto de entidades de nivel inferior
en una relación ES; es decir, los conjuntos de entidades de
este diagrama solo tienen herencia única. Si un conjunto de
entidades es un conjunto de entidades de nivel inferior es mas
de una relación ES, el conjunto de entidades tiene herencia
múltiple, y la estructura resultante se denomina retículo.
La generalización es una inversión simple de la
especialización. Se aplicarán ambos procesos, combinados,
en el transcurso del diseño del esquema E-R de un proyecto.
Los niveles nuevos de representación de las entidades se
distinguen (especialización) o se sintetizan (generalización)
cuando el esquema del diseño llega a expresar
completamente la aplicación de la base de datos y los
requisitos del usuario de la base de datos. Las diferencias
entre los dos enfoques se pueden caracterizar mediante su
punto de partida y su objetivo global.
GENERALIZACIÓN
La especialización parte de un único conjunto de

entidades; destaca las diferencias entre las entidades
del conjunto mediante la creación de diferentes
conjuntos de entidades de nivel inferior. Esos conjuntos
de entidades de nivel inferior pueden tener atributos o
participar en relaciones que no se aplican a todas las
entidades del conjunto de entidades de nivel inferior.
Realmente, la razón de que el diseñador aplique la
especialización es poder representar esas características
distintivas. Si cliente y empleado no tuvieran atributos
que no tuvieran las entidades persona ni participaran en
relaciones diferentes de las relaciones en las que
participan las entidades persona, no habría necesidad
de especializar el conjunto de entidades persona.
GENERALIZACIÓN
La generalización parte del reconocimiento de que

varios conjuntos de entidades comparten algunas
características comunes (es decir, se describen
mediante los mismos atributos y participan en los mismos
conjuntos de relaciones). Con base en esas similitudes, la
generalización sintetiza esos conjuntos de entidades en
un solo conjunto de nivel superior. La generalización se
usa para destacar las similitudes entre los conjuntos de
entidades de nivel superior y para ocultar las diferencias;
también permite una economía de representación, ya
que no se repiten los atributos compartidos.
ESPECIALIZACIÓN Y GENERALIZACIÓN
Id_pers
ona nombre calle ciudad
persona
Calificacio
sueldo E n_crediticia
S
empleado cliente
E
S
oficial cajero secretaria
Num_de Horas_trab Horas_trab

Num_caja
spacho ajadas ajadas
Las subtablas se pueden almacenar de manera eficiente, sin
replica de todos los campos heredados de una de estas
maneras:
• Cada tabla almacena la clave primaria (que puede haber
heredado de una tabla madre) y los atributos que se definen
localmente. No hace falta almacenar los atributos
heredados (que no sean la clave primaria), se pueden
obtener mediante una reunión con la supertabla, de
acuerdo con la clave primaria.
• Cada tabla almacena todos los atributos heredados y
definidos localmente. Cuando se inserta una tupla, solo se
almacena en la tabla en la que inserta, y su presencia se
infiere en cada una de las supertablas. El acceso a todos los
atributos de las tuplas es mas rápido, ya que no hace falta
ninguna reunión.
No obstante, en caso de que el sistema de tipos permita que
cada entidad se represente en dos subtablas sin estar
presente en una subtabla en común a ambas, esta
representación puede dar lugar a la réplica de información.
Además, resulta difícil traducir las claves externas que hacen
referencia a una supertabla en restricciones de las subtablas
para implementar de manera eficiente esas claves externas
hay que definir la supertabla como vista, y el sistema de bases
de datos tiene que soportar las claves externas en las vistas.
Las implementaciones pueden decidir representar los tipos
arrays y multiconjuntos directamente o usar internamente una
representación normalizada. Las representaciones
normalizadas tienden a ocupar mas espacio y exigen un costo
adicional en reuniones o agrupamientos para unir datos en
arrays o multiconjuntos. Sin embargo puede que las
representaciones normalizadas resulten mas sencillas de
implementar.
Las interfaces de programas de aplicación ODBC y JDBC se han
extendido para recuperar y almacenar tipos estructurados; por
ejemplo, JDBC ofrece el método getObject(), que es parecido a
getString() pero devuelve un objeto Java Struct, a partir del cual se
pueden extraer los componentes del tipo estructurado. También es
posible asociar clases de Java con tipos estructurados de SQL y
JDBC puede realizar la conversión entre los tipos.
ODBC: Open DataBase Connectivity: El estandar de conectividad
abierta de bases de datos (ODBC) definido por Microsoft para su
utilización con lenguaje C es el estándar de interfaz de programas
de aplicación usado habitualmente. es la interfaz estratégica de
Microsoft para obtener acceso a datos en un entorno heterogéneo
de sistemas relacionales y no-relacionales de administración de base
de datos. Basado en la especificación de interfaz de nivel de
llamada del grupo de acceso SQL, ODBC proporciona una manera
abierta, independiente del proveedor de acceso a datos
almacenados en una variedad de bases de datos de mainframe,
minicomputadora y/o PC.
JAVA DATABASE CONNECTIVITY: JDBC
¿QUE ES JDBC?
"Es el acrónimo de Java Database Connectivity: Es una interfaz de programación
que permite la ejecución de operaciones sobre la Base de datos desde el
lenguaje de programación JAVA independientemente del sistema operativo
donde se ejecute o de la base de datos a la cual se accede utilizando el
dialecto SQL del modelo de la base de datos que se utilice".
"JDBC Es también una alternativa a ODBC.
JDBC la interfaz es más cómoda a los programadores Java que ODBC de interfaz
de lenguaje C".
¿PARA QUE SIRVE JDBC?

"JDBC es usado para enviar comandos SQL hacia una base de datos relacional,
que puede ser Oracle, Infomix, SyBase, etc".
"JDBC sirve para conectarse a una base de datos, y para cada base de datos
hay un driver JDBC diferente. Si la base de datos es remota, y el driver permite
conectar a una base de datos remota, por supuesto que se puede acceder a la
base de datos a través de Internet o de cualquier red, teniendo en cuenta
siempre firewall, proxy, etc., que pueden cerrarnos los puertos de conexión".
BIBLIOGRAFIA
• Database Systems a Practical Approach to Design,

Implementation, and Management.
• Fundamentos de Bases de Datos.
Silbershatz/Korth/Sudarshan. Editorial McGrawHill
Laboratorio. Utilizando funciones de Datawarehouse
1. Conectarse a sqlplus
C:\Users\root>sqlplus “/ as sysdba”
SQL*Plus: Release 11.2.0.1.0 Production on Mar Ago 25 23:04:02 2015
Copyright (c) 1982, 2010, Oracle. All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> shutdown immediate;

Base de datos cerrada.
Base de datos desmontada.
Instancia ORACLE cerrada.
SQL>
2. Iniciar instancia
C:\Users\root>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mar Ago 25 23:06:53 2015
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Conectado a una instancia inactiva.
SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 855982080 bytes

Fixed Size 2180544 bytes
Variable Size 507513408 bytes
Database Buffers 339738624 bytes
Redo Buffers 6549504 bytes
Base de datos montada.
Base de datos abierta.
SQL>
3. Realizar los siguientes queries con Oracle

CREATE TABLE ventas (
propiedad varchar2(15),
fecha DATE DEFAULT (sysdate),

ciudad varchar2(20),
precio NUMBER(10,2) NOT NULL);
insert into ventas values('Casa',sysdate, 'Toluca', 500);
insert into ventas values('Depto',sysdate, 'Mexico', 900);
insert into ventas values('Casa',sysdate, 'Mty', 400);
insert into ventas values('Casa',sysdate, 'Mexico', 1500);
insert into ventas values('Depto',sysdate, 'Toluca', 200);
insert into ventas values('Depto',sysdate, 'Mty', 800);
SQL> drop table ventas;
Tabla borrada.
SQL> CREATE TABLE ventas (

2 propiedad varchar2(15),
3 fecha DATE DEFAULT (sysdate),
4 ciudad varchar2(20),
5 precio NUMBER(10,2) NOT NULL);
Tabla creada.
SQL> insert into ventas values('Casa',sysdate, 'Toluca', 500);
1 fila creada.
SQL> ed
Escrito file afiedt.buf
insert into ventas values('Depto',sysdate, 'Mexico', 900);

insert into ventas values('Casa',sysdate, 'Mty', 400);
insert into ventas values('Casa',sysdate, 'Mexico', 1500);
insert into ventas values('Depto',sysdate, 'Toluca', 200);
insert into ventas values('Depto',sysdate, 'Mty', 800);
SQL> @afiedt.buf
1 fila creada.
1 fila creada.
1 fila creada.
1 fila creada.
1 fila creada.
SQL> select * from ventas;
PROPIEDAD FECHA CIUDAD PRECIO

--------------- -------- -------------------- ----------
Casa 19/10/15 Toluca 500
Depto 19/10/15 Mexico 900
Casa 19/10/15 Mty 400
Casa 19/10/15 Mexico 1500
Depto 19/10/15 Toluca 200
Depto 19/10/15 Mty 800
6 filas seleccionadas.
SQL> select propiedad,fecha,ciudad,sum(precio)

2 from ventas
3 group by rollup(propiedad,fecha,ciudad)
4 /
PROPIEDAD FECHA CIUDAD SUM(PRECIO)

--------------- -------- -------------------- -----------
Casa 19/10/15 500
Casa 19/10/15 Mty 400
Casa 19/10/15 1900
Casa 2400
Depto 19/10/15 Mty 800
Depto 19/10/15 1900
Depto 1900
4300
SQL> ed
1 select propiedad,fecha,ciudad,sum(precio) sales

2 from ventas
3* group by cube(propiedad,fecha,ciudad)
SQL> /
PROPIEDAD FECHA CIUDAD SALES

--------------- -------- -------------------- ----------
4300
Mty 1200
Mexico 2400
Toluca 700
19/10/15 500
19/10/15 Toluca 500
19/10/15 3800
19/10/15 Mty 1200
19/10/15 Mexico 2400
19/10/15 Toluca 200
Casa 2400
Casa Mty 400
Casa Mexico 1500
Casa Toluca 500
Casa 19/10/15 500
Casa 19/10/15 1900
Casa 19/10/15 Mty 400
Depto 1900
Depto Mty 800
Depto Mexico 900
Depto Toluca 200
Depto 19/10/15 1900
Depto 19/10/15 Mty 800
SQL> ed
Utilizar DENSE RANK
Table1
emp_id emp_name salary

1 name1 5000
2 name2 6000
3 name3 7000
4 name4 8000
WITH table1 AS(

SELECT 1 emp_id, 'name1' emp_name, 5000 salary FROM dual UNION ALL
SELECT 4 emp_id, 'name4' emp_name, 8000 salary FROM dual
)
SELECT emp_name
,DENSE_RANK() OVER (ORDER BY salary DESC) "Rank"
FROM table1;
4. Cargar un archivo de texto en una tabla de Oracle

tip utilizar la utilería de Oracle sqlldr
C:\Users\root>sqlldr
SQL*Loader: Release 11.2.0.1.0 - Production on Mar Oct 20 08:15:05 2015
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights
reserved.
Sintaxis: SQLLDR palabra_clave=valor [,palabra_clave=valor,...]
Palabras Clave Validas:
userid -- nombre de usuario/contraseña ORACLE

control -- nombre de archivo de control
log -- nombre de archivo log
bad -- nombre de archivo de errores
data -- nombre de archivo de datos
discard -- nombre de archivo de desechos
discardmax -- numero de desechos permitidos (Por defecto todo)
skip -- número de registros lógicos que saltar (Por defecto 0)
load -- número de registros lógicos que cargar (Por defecto
todo)
errors -- numero de errores que permitir (Por defecto50)
rows -- numero de filas en la matriz de enlace de ruta de acceso
convencional o entre almacenamientos de datos de ruta de acceso directa
(Por defecto: Ruta de acceso convencional 64, ruta de
acceso directa todos)
bindsize -- tama±o de la matriz de enlace de ruta de acceso
convencional en bytes (Por defecto 256000)
silent -- suprimir mensajes durante la ejecuci¾n
(cabecera,feedback,errores, desechos,particiones)
direct -- usar ruta de acceso directa (Por defecto FALSE)
parfile -- archivo de parametros: nombre del archivo que contiene
especificaciones de parametros
parallel -- realizar carga paralela Por defecto FALSE)
file -- archivo desde el que asignar extensiones
skip_unusable_indexes -- permitir/no permitir índices no utilizables o
partición es de indice (Por defecto FALSE)
skip_index_maintenance -- no mantener índices, marcar índices afectados
como no utilizables (Por defecto FALSE)
commit_discontinued -- confirmar filas cargadas cuando la carga sea
discontinua (Por defecto FALSE)
readsize -- tamaño del buffer de lectura (Por defecto 1048576)
external_table -- usar tabla externa para carga; NOT_USED,
GENERATE_ONLY, EXECUTE (Por defecto NOT_USED)
columnarrayrows -- numero de filas para la matriz de columna de ruta de
acceso directa (Por defecto 5000)
streamsize -- tamaño del buffer de flujo de ruta de acceso directa en
bytes (Por defecto 256000)
multithreading -- usar multithread en ruta de acceso directa
resumable -- activar o desactivar reanudaci¾n de sesión actual (Por
defecto FALSE)
resumable_name -- cadena de texto para ayudar a identificar sentencia
de reanudación
resumable_timeout -- tiempo de espera (en segundos) para RESUMABLE
(Por defecto 7200)
date_cache -- tamaño (en entradas) de la cache de conversión de fechas
(Por defecto 1000)
no_index_errors -- errores al abortar la carga en un índice (Por
defecto FALSE)
ATENCION: Los parámetros de la línea de comandos se pueden especificar

mediante
Posición o palabras clave. Un ejemplo del primer caso es 'sqlldr
scott/tiger foo'; un ejemplo del segundo es sqlldr control=foo
userid=scott/tiger'. Se pueden especificar parametros por posici¾n
antes pero no despues de los especificados por palabras clave. Por
ejemplo,
'sqlldr scott/tiger control=foo logfile=log' está permitido, pero
'sqlldr scott/tiger control=foo log' no, a pesar de que la
posicion del parametro 'log' sea correcta.

DB Avanzadas

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

DB Avanzadas

Încărcat de

Drepturi de autor:

Formate disponibile

Modelo de almacenamiento de 1er nivel

Modelo orientado a objetos (OODM):

OLTP: On-Line Transactional Processing

EDW (Datawarehouse empresarial)

2. Menciona dos tipos de persistencias en OODBMS

3. ¿Qué son los tipos de datos complejos?

Hacer el ejemplo de la inserción de un registro a esta tabla de clintes:

6. ¿Qué elementos puede encontrar en los documentos xml?

7. Mencione al menos dos tecnologías relacionadas con xml

9. ¿Qué es datawarehouse y que tipo de procesamiento se utiliza?

10. ¿Qué es un datamart?

Con la metodología de Inmon un data mart es la implementación física de la base de

1. Describa uno de los modelos de dimensionalidad

2. Realice el query y la salida del mismo de la siguiente tabla utilizando ROLLUP

A diferencia de otros el lenguaje Extensible Markup

Para comprender XML es importante entender sus raíces

Para la familia de lenguajes de marcado, en los que

<title> Bases de Datos Avanzadas </title>

A diferencia de HTML, XML no impone las etiquetas

En primer lugar la presencia de las etiquetas hace que el

En tercer lugar, XML permite estructuras anidadas. El pedido de compra

Finalmente, puesto que el formato XML esta

El constructor fundamental de un documento XML es el elemento. Un

Por ejemplo, un pedido de compra almacenaría la dirección

Los atributos de un elemento aparecen como pares nombre=valor

Un documento puede tener mas de un espacio de nombres,

<![CDATA[<cuenta> .... </cuenta>]]>

XML. Es un metalenguaje (un lenguaje para describir otros lenguajes)

Al contrario, XML esta diseñado para complementar

XML declaration <?xml version=“1.1” encoding=“UTF-8”

Elementos o tags <staff> </staff>

Entity reference &lt;

Comments

Sección CDATA y <?name pidata?>

En contraste RDBMS requieren un esquema orientado de

Es deseable tratar orígenes de Web como una base de datos, pero

DTD define la sintaxis valida de un documento XML listando

<STAFF branchno = “B003”>

<!ELEMENT STAFFLIST (STAFF)*>

Declaraciones de listas de atributos

Declaraciones de entidades y notaciones

<!ENTITY DH “DreamHome Estate Agents”>

La presencia de entidades externas sin procesar es la responsabilidad de la

<!ENTITY dreamHomeLogo SYSTEM “dreamhome.jpg” NDATA JPEGFormat>

La presencia del token NDATA indica que la entidad no es procesada; el nombre

Element identity, IDs and ID Reference

<!ATTLIST STAFF staffNo ID #REQUIRED>

Entonces se podrán utilizar estos atributos como se muestra en la siguiente

<STAFF staffNo = “SL21”>

El procesador de validación no solo revisará que el documento XML sea well-

como agregar, borrar y reordenar elementos.

SL21 Manager 1945-10-01 30000

SAX (Simple API for XML) es una aplicación basada

<?xml version = “1.1”?>

XPath define 13 tipos de ejes, incluyendo parent,

En este caso se seleccionan ambos nodos de STAFF.

XLink (XML Linking Language)

Simple Object Access Protocol (SOAP)

<?xml version = “1.1”?>

Web Services Description Language (WSDL)

<xs:element name = “STAFFLIST”>

Cada uno de los elementos en el esquema tiene un prefijo xs:,

<xs:element name = “DOB” type = “xs:date” minOccurs=“0”/>

Definiendo nuevos tipos

Entity reference <