Transcript Clase_10 BD Distribuidas, Paralelas y WWW

Unidad 10
Tecnologías Emergentes de
Bases de Datos
Objetivos: Conocer las diferentes tecnologías
emergentes en bases de datos y sus aplicaciones.
Emergent Database Technologies
Objectives: Get introduced on emergent technologies in
databases and their applications.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
1
Contenidos
• Revisaremos las principales tecnologías
emergentes de bases de datos que de
alguna manera están vigentes en la
actualidad:
–
–
–
–
–
–
Bases de Datos Activas
Bases de Datos Orientadas a Objetos
Bases de Datos Distribuídas
Bases de Datos Espaciales y Temporales
Bases de Datos Multimediales
DataWarehouse y DataMining
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
2
Introducción
• Se cumplen ya más de treinta años desde
que el Dr. Codd propuso el modelo relacional
en 1970, dando lugar a la "segunda
generación" de productos de bases de datos:
ORACLE, DB2, INGRES, INFORMIX, SYBASE,
etc. que presentan una mayor independencia
físico/lógica, mayor flexibilidad y lenguajes
de especificación (que actúan sobre
conjuntos de registros).
• Este tipo de productos se ha impuesto en el
mercado y ha sido uno de los principales
focos de investigación durante las décadas
de los setenta y ochenta.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
3
Introducción - 2
• En los últimos años hemos asistido a un avance
espectacular en la tecnología de bases de
datos.
• Aparecen :
– Bases de datos multimedia
– Activas
– Deductivas
– Distribuídas
– Orientadas a Objetos
– Seguras
en las últimas versiones de algunos DBMS y en
nuevos productos
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
4
Introducción - 3
• Esta nueva generación de bases de datos (la
"tercera"), se caracteriza por proporcionar
capacidades de gestión de datos, objetos y
gestión de conocimiento.
• Pretende responder a las necesidades de
aplicaciones tales como: CASE (Ingeniería del
software asistida por ordenador),
CAD/CAM/CIM, SIG (sistemas de información
geográfica), información textual, aplicaciones
científicas, sistemas médicos, publicación
digital, educación y formación, sistemas
estadísticos, comercio electrónico, etc.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
5
Introducción - 4
• Todas estas nuevas tecnologías
afectan al proceso de diseño de bases
de datos, que resulta cada día más
difícil, así como a la administración de
los sistemas.
• Por otra parte, también se establece el
desarrollo de nuevos estándares como
el ODMG y el SQL1999 (hasta ahora
conocido como SQL3), que recojen las
características de esta nueva
generación.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
6
Bases de Datos Activas
• Los sistemas de bases de datos activas
(Active DataBase Management System ADBMS) han sido un área importante de
investigación los últimos años,
principalmente por la necesidad de contar
con “funcionalidad activa” en los
sistemas de información.
• Conceptos como “objetos activos” y
“eventos” son utilizados en muchas áreas
de investigación tecnológica, aún más
allá de los sistemas de bases de datos.
• Aún no esta absolutamente claro que
funcionalidad debe soportar un DBMS
para ser considerado un sistema activo.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
7
ADBMS - 2
• Se distinguen algunos conceptos y características que se
deben cumplir obligatoriamente para considerar un DBMS
como un sistema activo, a su vez otro grupo de estas son
características “deseables” en este tipo de sistemas.
• Las Bases de Datos activas pretenden la generación de
sistemas autónomos o semi-autónomos.
• El concepto de sistema activo, conlleva que de alguna manera
los sistemas deben contar con un mecanismo que les permita
estar “al tanto” de lo que sucede a su alrededor.
• El concepto de “Evento” y “Respuesta” es un paradigma para
muchos de los sistemas de información futuros, y ya que se
trata de un fenómeno horizontal, las tecnologías de bases de
datos han tenido que simplemente sumarse al paradigma
evento-respuesta.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
8
ADBMS - 3
• En otras palabras, todos los DBMS futuros, sean
relacionales, orientados a objetos deberán
mostrar alguna funcionalidad activa.
• En la actualidad, los ADBMS han logrado un buen
nivel de madurez, y las funcionalidades activas ya
se encuentran presentes en muchos DBMS.
• En los ADBMS se ha definido un set de reglas
denominadas ECA-Rules (Event-Condition-Action
rules), que consiste en eventos, condiciones y
acciones. El significado de una regla de este tipo
es: “Cuando un evento ocurra, verifique las
condiciones, y si aplica, ejecute la acción”.
• En tecnologías de bases de datos son utilizados
comúnmente otros términos, por ejemplo
Triggers.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
9
Evento-Condición-Acción
Event-Condition-Action ECA-Rules:
• Una vez que un set de reglas ha sido definidas el
ADBMS monitorea los eventos relevantes. Un
evento relevante es aquel que tiene definida
alguna regla.
• Cada vez que el ADBMS detecta la ocurrencia de
un evento relevante, notifica al componente
encargado de la ejecución de la regla asociada.
Esta notificación se denomina “event signalling” o
señalización de eventos.
• En consecuencia, todas las reglas definidas para
responder a dicho evento se “gatillan” (trigger), y
deben ser ejecutadas.
• La ejecución de reglas incorpora la evaluación de
condiciones, y si dichas condiciones satisfacen, se
ejecuta la acción.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
10
Características de un ADBMS
• Una base de datos puede considerarse
activa si cumple al menos las
siguientes características:
• ECA-Rules
1. Un ADBMS es un DBMS:
• Todos los conceptos requeridos en un DBMS pasivo
están presentes en un ADBMS. Esto significa que si un
usuario desconoce las funcionalidades activas, un
ADBMS se comportará exactamente como un DBMS.
2. Un ADBMS contiene un modelo ECA-Rule:
• Un ADBMS extiende las funcionalidades de un DBMS de
manera de soportar un comportamiento reactivo. Dicho
comportamiento debe ser especificable / definible por
el usuario.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
11
Características de un ADBMS…
– 2.a. Un ADBMS debe proveer funcionalidad
para la definición de tipos de eventos:
• Un tipo de evento describe las situaciones a las
cuales una reacción debe ser asociada.
• En la medida que se requiera, se puede definir
eventos que se señalizan antes o después de
ocurrida la operación.
• Existen 2 tipos de eventos: primitivos y
compuestos.
• Los eventos primitivos son elementales, por
ejemplo, modificación de datos, invocación de
métodos, y eventos de tiempo.
• Los eventos compuestos son eventos que agrupan
un conjunto de eventos primitivos e incluso otros
eventos compuestos.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
12
Características de un ADBMS
2.b. Un ADBMS debe proveer funcionalidad para la
definición de condiciones:
Una condición establece las situaciones en las cuales se
deberá ejecutar alguna acción, puede ser un predicado en
una sentencia de la base de datos, por ejemplo WHERE en
una sentencia SQL, o bien una consulta (query) que retorna
resultado vacío o no-vacío.
La condición se satisface cuando o bien el resultado evalúa
verdadero y bien es no-vacío.
2.c. Un ADBMS debe proveer funcionalidad para la
definición de acciones:
Una acción establece la reacción a un evento cuando se
cumple la condición. Una acción puede contener
operaciones de actualización de datos selección,
operaciones de transacciones tales como commit o
rollback, etc.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
13
Características de un ADBMS
3. Un ADBMS debe soportar administración
de reglas y su evolución:
3.a.El set de reglas debe ser administrado por el ADBMS,
en otras palabras, las definiciones de ECA-Rules son
parte de la base de datos. El ADBMS debe mantener
información respecto de qué reglas existen y cómo
estan definidas. Esta información debe ser visible a
usuarios y aplicaciones.
3.b. El ADBMS debe proveer capacidad para que el set de
reglas pueda evolucionar en el tiempo, esto es
posibilitar la creación de nuevas reglas, eliminación,
modificación de eventos relevantes, condiciones y
acciones derivadas.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
14
Características de un ADBMS
3.c.El ADBMS debe soportar la habilitación y deshabilitación
de reglas.
Al deshabilitar una regla su definición se mantiene en la
base de datos, sin embargo esta no será gatillada ante la
ocurrencia del evento.
Variaciones de las reglas ECA:
• Omisión de la condición: (EA Rule): en este caso se omite
la condición, es decir, la acción asociada al evento
siempre se ejecuta.
• Eventos Implícitos: (CA Rule): en este caso el es DBMS el
que genera la definición del evento, dejando al usuario la
definición de las condiciones y acciones.
Este es el caso cuando se utilizan Triggers para la
implementación de funcionalidad activa.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
15
Características de un ADBMS
4. Un ADBMS contiene un modelo de ejecución:
4.a.Un ADBMS debe detectar ocurrencias de eventos.
4.b. El ADBMS debe soportar modos de acoplamiento:
• Orientado a la instancia: significa que instancias
particulares (por ejemplo registros específicos) para la
cual ocurrió un evento, pueden ser referenciadas
individualmente por condiciones y acciones. Cuando un
evento ocurre, la condición y acción se aplica a cada
instancia separadamente.
• Orientado al conjunto: cuando un evento ocurre, la
condición y acción se aplica a todas las instancias única
vez (por ejemplo, registros modificados de una relación).
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
16
Características de un ADBMS
4.c. Un ADBMS debe ser capaz de evaluar condiciones, la
información de objetos sobre los cuales ocurrió una
acción puede ser referida por la condición.
4.d. Un ADBMS debe ser capaz de ejecutar acciones: una
vez detectado un evento, y luego que la condición
evalúe verdadero.
Debe ser posible pasar información desde el evento y la
condición a la acción, (por ejemplo registros para los
cuales la condición evalúa V).
Debe ser posible ejecutar otras acciones como parte de
la transacción, y la ejecución de dichas acciones estarán
sujetas a control de concurrencia y recuperación.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
17
Características de un ADBMS
5. Un ADBMS debe proveer diferentes modos de
acoplamiento: La relación entre transacción “que invoca” y
la transacción “invocada” debe ser posible de especificar a
través de “modos de acoplamiento” o “coupling modes”.
Los modos de acoplamiento originalmente propuestos son:
• Inmediato: la transacción invocada se ejecuta directamente
luego de la señalización del evento.
• Diferido: la transacción invocada se ejecuta al final de la
transacción “invocadora”, pero antes de que los cambios se
hagan permanentes.
• Desacoplado: la transacción invocada se ejecuta como una
transacción independiente.
En los 2 primeros casos, la transacción invocada es en la práctica
una subtransacción de la primera, en el último caso es otra
transacción completamente independiente.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
18
Características de un ADBMS
•
Un ADBMS debe implementar “modos de
consumo”:
Si el ADBMS soporta eventos compuestos, debe
implementar “consumo de eventos” o “event
consumption”. Este mecanismo determina qué eventos
componentes son considerados para un evento
compuesto, y cómo los parámetros de dichos eventos
son computados por sus componentes.
En la práctica un ADBMS puede proveer un único
modelo de “consumo de eventos” o bien implementa
diferentes alternativas en una colección de modos de
consumo”
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
19
Características de un ADBMS
7. Un ADBMS debe administrar historia de eventos o
“event history”.
• Un ADBMS debe almacenar la historia de ocurrencia de
eventos, desde que el primer evento es detectado.
• La historia eventualmente podrá prevalecer luego de
múltiples sesiones y múltiples transacciones.
• La persistencia de la historia de eventos será requerida
siempre que sea posiible señalizar un evento
compuesto basado en eventos que ocurrieron durante
diferentes instancias o sesiones de la aplicación o
transacciones.
• Se define entonces el concepto de “tiempo de vida” de
la historia, en forma mínima, un ADBMS debe
almacenar la historia de ocurrencias de eventos que
aún puedan ser utilizados por eventos compuestos.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
20
Características de un ADBMS
8. Un ADBMS debe implementar resolución de
conflictos.
Por la naturaleza de los sistemas de información, puede
suceder que varias transacciones gatilladas se ejecuten
en un determinado momento del tiempo. El ADBMS
debe realizar “resolución de conflictos”, por ejemplo,
determinar la ejecución serializada de las transacciones,
o bien paralela controlando la concurrencia.
9. Un ADBMS debe soportar un ambiente de
programación: las características de un ADBMS deben
ser “usables” a través de un lenguaje de definición de
reglas, normalmente una extensión del DDL.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
21
Características de un ADBMS
10.Un ADBMS debe poder ser optimizable.
Por definición el uso de un ADBMS debe suponer que la
performance no será degradada respecto de un sistema
basado en una arquitectura pasiva.
Aunque parece algo bastante obvio, es de extrema
importancia que un ADBMS provea herramientas de
optimización que permitan la NO degradación de la
performance.
Si esta característica tan básica es ignorada, en forma
natural este tipo de sistemas tenderá a desaparecer, o
bien su utilización se limitará a grandes instalaciones o
aplicaciones específicas.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
22
Bases de Datos Objeto-Relacionales
(Object – Relational OR)
Limitaciones del Modelo Relacional:
• En el tiempo ha quedado demostrado que los modelos
de bases de datos relacionales son en extremo
poderosos en aplicaciones tradicionales de bases de
datos (sistemas de negocios o sistemas de información
administrativo).
• Además de su simplicidad, el concepto de TABLA ofrece
una aproximación ideal para la representación de “datos
del negocio” o “bussines data”.
• Sin embargo, cuando el modelo relacional es aplicado en
soluciones informáticas que no estan relacionadas a la
administración de los “datos del negocio”, tales como
aplicaciones de CAD, imágenes, multimedia, información
geográfica... Se hace obvio que el modelo relacional no
es el más apropiado.
• Este tipo de aplicaciones involucra datos y estructuras
extremadamente complejas para ser representadas en
la tradicional estructura de tabla “plana”.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
23
Limitaciones del Modelo
Relacional
Estructuras de
Datos Complejas
Atributos
Multivalor
BLOBs / CLOBs
Jerarquía y
Herencia
Operaciones
Tipo-Específicas
Bajo nivel de soporte a estructuras de
datos complejas.
Requiere la creación de nuevas entidades
y relaciones.
Pérdida de información sobre la estructura
de los atributos.
Bajo nivel de soporte a grandes
volúmenes de información binaria y de
texto.
Requiere operaciones de join explícitas.
No permite referencia a atributos
“heredados” de una relación.
No provee soporte para la especificación
y construcción de operaciones tipoespecíficas.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
24
Atributos Multi-Valor
• Dos de las primeras limitaciones del modelo
relacional, nacen de sus restricciones
estructurales:
– En un modelo relacional, se debe descomponer
los atributos en busca de una expresión atómica
e indivisible.
– Para aquellos atributos que involucran listas de
valores (multi-valor), dichos valores deben ser
mapeados en una tabla diferente.
• Como resultado la información sobre la
estructura de los atributos se pierde y los
datos están diseminados en múltiples
relaciones.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
25
Jerarquía (ISA Hierarchy)
• Debido a que el modelo relacional no permite expresar directamente
las jerarquías, no podemos usar el concepto de “Herencia” para la
simplificación de querys.
• Por ejemplo, dadas las tablas:
MEMBER(MemberId, Fname, MI, Lname)
LIFE_MEMBER(MemberId, Year)
• En el modelo relacional, para obtener el nombre de un LIFE_MEMBER
será necesario realizar en forma explícita la navegación a través de
las relaciones (operación de join):
Select M.Fname, M.MI, M.Lname
From MEMBER M, LIFE_MEMBER LF
Where LF.MemberId = M.MemberId
• En un modelo objeto – relacional, la operación de join es implícita,
aplicando el concepto de herencia, esto es, todos los atributos de
MEMBER son heredados por LIFE_MEMBER:
Select Fname, MI, Lname
From LIFE_MEMBER
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
26
Binary Large Objects (BLOBs)
• Los DBMS relacionales soportan el uso de strings de bits y
data binaria en general, sin embargo, su soporte es limitado
normalmente orientado a “pequeños” volúmenes de datos,
como gráficos o imágenes.
• En general, grandes volúmenes de data binaria no son
soportados por un DBMS relacional, tales como video clips de
cientos de megabytes.
• Incluso si por un momento ignoramos estas limitaciones
estructurales y asumimos que se puede almacenar un BLOB
en una tabla, es imposible consultar esta información usando
SELECT. Por ejemplo, cómo obtener la secuencia de cuadros
entre el 13 y 27 de un video blob.
• Este tipo de operaciones requiere de implementaciones
particulares, como getframe(from, to).
Los DBMS relacionales no proveen especificación para
operaciones tipo-específicas.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
27
Character Large Objects (CLOBs)
• Similar situación se presenta en objetos de
grandes volúmenes de información alfanumérica,
tales como data semi-estructurada, páginas html,
etc.
La Solución ...
Tipos de Datos y Objetos defindos
por el Usuario
(User-Defined Data Types and Objects)
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
28
Abstract Data Types (ADTs)
• Los problemas que surgen con el manejo de BLOBs y
CLOBs son ilustrativos del problema generalizado que
presenta la falta de soporte a tipos de datos y funciones
definidas por el usuario en los DBMS relacionales.
• Los problemas que surgen de complejas estructuras de
datos que requieren ser manipuladas de una manera
específica pueden ser ambos resueltos “encapsulandolos”
como “Tipos de Datos Abstractos” o “Abstract Data
Types” (ADTs).
• Los ADTs han sido exitosamente utilizados en lenguajes
de programación para administrar de una manera más
efectiva el desarrollo y mantención de grandes sistemas
de información.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
29
Abstract Data Types (ADTs)
Complejas
Estructuras de
Datos
Rutinas de
Manipulación
Específica
User-Defined
Data Types and
Objects
ADTs (Abstract Data Types)
Especificación Estructura
de Datos Visible y
Operaciones Permitidas
Implementación de Estado,
relaciones con otros ADTs
y sus operaciones
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
30
Abstract Data Types (ADTs)
Un ADT consiste en:
• Una especificación de sus estructuras de datos visibles y
operaciones permitidas, y
• Una implementación de su estado, relaciones con otros
ADTs y sus operaciones.
• Si un ADT es utilizado para definir el dominio de una columna,
entonces las operaciones definidas en dicho ADT pueden ser
utilizadas en queries y transacciones para manipular los valores
de la columna.
• Puede ser pensado como el tipo de un objeto, en otras
palabras, un objeto puede ser interpretado como una instancia
de un tipo de datos abstracto (ADT).
• La idea de “Herencia” de estado y operaciones que provienen
de la programación orientada al objeto pueden ser aplicados a
objetos y ADTs en bases de datos.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
31
Abstract Data Types (ADTs)
ADT
Tipo de un Objeto
Herencia de Estado y Operaciones
Si un ADT es utilizado para definir una columna, entonces las
operaciones definidas en dicho ADT pueden ser utilizadas en
queries y transacciones para manipular los valores de la columna
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
32
Tendencias
• La introducción a ADTs y objetos como medio de soporte
a aplicaciones de bases de datos avanzadas, ha tomado
varias formas, dos de las cuales —object-relational
databases y object-oriented databases— están en
proceso de estandarización.
• La primera aproximación (object – relational) extiende el
modelo relacional con ADTs y objetos y se espera este
estandarizada con SQL3, la siguiente versión de SQL.
• La segunda aproximación (object – oriented) extiende
un lenguaje de programación orientado a objetos
(tipicamente C++), con conceptos propios de bases de
datos, tales como persistencia.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
33
Tendencias
Base de Datos
Objeto-Relacional
Base de Datos
Orientadas a
Objetos
Extiende el modelo relacional con ADTs y
objetos, estandarizada con SQL3 (o SQL99),
la siguiente versión de SQL.
Extiende un lenguaje de programación
orientado a objetos (típicamente C++ o Java),
con conceptos propios de bases de datos.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
34
Tendencias
• Un estándar de modelo de datos orientado al objeto
es propuesto por el grupo ODMG (Object Database
Management Group). Otro proceso de definición de
estándares esta siendo llevado a cabo por OMG
(Object Management Group), y su iniciativa empuja
por un modelo estándar cliente-servidor orientado a
objetos denominado CORBA (Common Object
Requester Broker Architecture).
• En este punto es importante mencionar que existe
una gran transposición entre las 3 ramas de
estandarización, y en este sentido los esfuerzos se
han desarrollado en paralelo.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
35
Tendencias
Estándar ODMG
Base de
Datos
Orientadas
a Objetos
Estándar OMG
Propuesto por el grupo ODMG
(Object Database Management
Group).
OMG (Object Management Group),
su iniciativa empuja por un modelo
estándar cliente-servidor orientado
a objetos denominado CORBA
(Common Object Requester Broker
Architecture)
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
36
Object Relational Databases
& SQL3
• El modelo Objeto Relacional extiende el modelo relacional con
características de orientación a objetos (OO), manteniendo el acceso
declarativo a los datos.
• SQL3 ha sido diseñado para estandarizar el soporte para ADTs y
objetos, manteniendo compatibilidad con SQL2 (SQL tradicional).
• Las características de orientación a objetos presentes en SQL3
incluyen:
• Identificador de Objeto y tipos de referencias.
• Tipos de Datos complejos y representaciones no-1FN (relaciones
anidadas, listas de valores).
• Herencia de tipo y tabla.
• Querys y funciones complejas.
• SQL3 adicionalmente intenta estandarizar los procedimientos
almacenados, o módulos almacenados persistentes (persistent stored
modules), extensiones multimedia , lenguaje de definición de
transacciones, y una interface para aplicaciones (application interface)
similar a ODBC.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
37
Collection Types (colecciones)
• Los tipos colección (collection types) permiten la definición de
entidades con columnas multi-valor (listas de valores).
• Una columna multi-valor se declara a través de alguno de los
constructores de tipos colecciones (collection type constructors):
• ARRAY: arreglo unidimensional de tamaño fijo
• SET: una colección desordenada, sin duplicados
• LIST: una colección ordenada, con duplicados
• MULTISET: una colección desordenada, con duplicados
• Por ejemplo, consideremos la tabla DOCUMENT con dos columnas de
tipo colección: una lista de autores, y un set de palabras clave
(keywords):
CREATE TABLE DOCUMENT
(title
CHAR(20),
revision
DATE,
keyword
SET(CHAR(10)),
authors
LIST(CHAR(10)))
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
38
Collection Types (colecciones)
• Los constructores de tipos también pueden ser utilizados para
construir querys, por ejemplo:
SELECT title, revision
FROM DOCUMENT
WHERE title in SET ('DBS', 'DDBS', 'MDBS');
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
39
Tipos de Datos definidos por el usuario
• Los usuarios pueden especificar nuevos tipos de datos (User-
Defined Types) usando el comando CREATE TYPE.
• Por ejemplo, podemos usar las dos sentencias siguientes para
definir un tipo de dato atómico alfanumérico, y un tipo de dato
estructurado que llamaremos “MyDate”.
CREATE TYPE String AS VARCHAR(30)
CREATE TYPE MyDate
(day
integer,
month char(3),
year integer)
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
40
User-Defined Types
• Los tipos de datos definidos por los usuarios pueden
ser utilizados en la definición de otros tipos de datos,
y en la especificación de columnas de una tabla
usando la sentencia CREATE TABLE.
• Por ejemplo,
CREATE TABLE DOCUMENT
(title CHAR(20),
revision
MyDate,
keyword
SET(CHAR(10)),
authors
LIST(CHAR(10)))
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
41
Row Types (Tipos de Filas)
• Un tipo de dato estructurado especial es el row type (tipo de
fila/registro), que puede representar los tipos de filas en una tabla.
CREATE ROW TYPE Doc_row
(title
String,
revision
MyDate,
keyword
SET(String),
authors
LIST (String))
• Al definir las filas de una tablas como tipos de datos, podemos
asignarlos a variables y usarlos como argumentos en funciones.
• Definamos la tabla DOCUMENT:
CREATE TABLE Document OF TYPE Doc_row
• Completando la definición:
CREATE TABLE Document OF TYPE Doc_row
(PRIMARY KEY (title))
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
42
Type Inheritance
(Herencia de Tipo)
• El modelo O-R soporta tanto herencia simple como múltiple.
• Herencia simple: hereda de solo un objeto.
• Herencia múltiple: hereda de dos o más objetos.
• La Herencia se especifica usando el comando UNDER.
• Como ejemplo de herencia simple, consideremos el ejemplo
clásico de Estudiante y Profesor, ambos derivados de Persona:
CREATE TYPE Person (name String, ssn integer)
CREATE TYPE Student (degree String, dept String)
UNDER Person
CREATE TYPE Teacher (salary integer, dept String)
UNDER Person
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
43
Type Inheritance
(Herencia de Tipo)
• Como ejemplo de herencia múltiple, consideremos a los
profesores ayudantes , que son tanto alumno como
profesor:
CREATE TYPE TA
UNDER
Student WITH (dept as student-dept),
Teacher WITH (dept as teacher-dept);
• Usamos la cláusula WITH para resolver ambigüedades en
atributos con nombres comunes, en el caso anterior
tanto Student como Teacher tienen un atributo llamado
dept.
• Debe quedar establecido que una entidad puede tener
un solo tipo, el más específico o de más alto nivel. Por
ejemplo, una entidad no puede ser un TA y Teacher al
mismo tiempo.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
44
Table Inheritance
(Herencia de Tabla)
• Opuesto a la herencia de tipo, la herencia de tabla
permite que un objeto pertenezca a múltiples
tablas.
• Revisemos los siguientes ejemplos de herencia
simple:
CREATE TABLE Person (name String, ssn integer)
CREATE TABLE Student (degree String, dept
String) UNDER Person
CREATE TABLE Teacher (salary integer, dept
String) UNDER Person
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
45
Table Inheritance
(Herencia de Tabla)
• Nótese que cada sub-tabla hereda cada columna
de su super-tabla.
• Dado lo anterior, significa que una fila
correspondiente a un profesor ayudante (tabla TA)
pertenece a ambas tablas Student y Teacher.
• Una restricción de herencia simple, es que cada fila
en una super-tabla (Person), puede corresponder a
una tupla de una sub-tabla (Student y Teacher), y
vice-versa.
• Las operaciones de INSERT, DELETE, y UPDATE son
apropiadamente propagadas.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
46
Object IDs and Reference Types
(Ids de Objetos y Tipo de Referencia)
• Una llave es un conjunto de propiedades de una
tabla que permiten identificar en forma única un
registro.
• Cuando un registro es asignado a una variable o
pasado como parámetro en una rutina o función,
entonces la llave de alguna manera pierde sentido.
• Por otro lado, un ID de Objeto (OID) es un
identificador de sistema único que puede ser
utilizado para referenciar un registro (o un objeto)
en cualquier contexto.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
47
Object IDs and Reference Types
(Ids de Objetos y Tipo de Referencia)
• En el modelo OR, los registros (filas de una tabla) pueden ser
asociadas con OIDs usando la opción WITH OID.
CREATE ROW TYPE people_row
(Name String, Birthday DATE)
WITH OID
CREATE TABLE Person of TYPE people_row
• Y referenciada usando la palabra reservada REF:
CREATE TABLE Document1
( title String,
revision DATE,
keyword SET(String),
authors LIST(REF(Person)),
PRIMARY KEY (title))
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
48
Object IDs and Reference Types
(Ids de Objetos y Tipo de Referencia)
• En el ejemplo anterior, se referencia la Tabla en authors.
Alternativamente, podemos referenciar vía Row Type.
• Si existen varias tablas del mismo tipo de fila, entonces
pedemos restringir una referencia a una tabla específica
usando la cláusula SCOPE FOR.
• Como ejemplo, re escribamos el comando CREATE TABLE
anterior:
CREATE TABLE Document1
( title String,
revision DATE,
keyword SET(String),
authors LIST(REF(people_row)),
SCOPE FOR authors IS Person,
PRIMARY KEY (title))
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
49
Querys y tipos de datos complejos
• Podemos referenciar los componentes de una fila, a
través de la construcción de una expresión de path,
usando notación de doble punto.
• Por ejemplo, consideremos el query que lista los
títulos y nombres de autores de todos los
documentos asociados a la palabra clave
“database”. La expresión de path aquí es
Document1.authors..Name
SELECT Document1.title, Document1.authors..Name
FROM Document1
WHERE 'database' in keyword
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
50
Querys y tipos de datos complejos
• Un Tipo Colección (Collection Type), tal como el
resultado de una expresión de path, puede aparecer
en la cláusula FROM.
• Por ejemplo, el query anterior puede ser escrito
usando el tipo de colección B.authors en la cláusula
FROM como se muestra a continuación:
SELECT B.title, Y.name
FROM Document1 as B, B.authors as Y
where 'database' in keyword
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
51
User-Defined Functions
(Funciones definidas por el usuario)
• Una función definida por el usuario puede ser escrita tanto en
SQL o en un lenguado de alto nivel como C y C++, en este
último caso la función es compilada externamente pero es
cargada y ejecutada como parte del DBMS.
• La estructura general de una función definida por el usuario
es la siguiente:
CREATE FUNCTION (params) RETURNS <type> AS <sql>
• Como un ejemplo de función en SQL, consideremos la función
que cuenta el número de autores de un documento:
CREATE FUNCTION author-count (ADOC Document)
RETURNS integer AS
SELECT COUNT(authors)
FROM ADOC
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
52
User-Defined Functions
(Funciones definidas por el usuario)
• Esta función puede ser utilizada en cualquier otro
query, por ejemplo:
SELECT title
FROM Document d
WHERE author-count(d) > 1
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
53
Insertando Valores en estructuras
complejas
• Los comandos DELETE y UPDATE en el modelo OR
son lo mismo que en el modelo tradicional.
• INSERT tambien es bastante similar, pero
requieren la utilización del constructor SET para
atributos multi-valor (tipos de datos de colección o
collections types).
• Por ejemplo, consideremos la operación de INSERT
de la tabla Document, la cual contiene atributos
multi-valor en autores y keywords:
INSERT INTO Document (title,revision,authors,keyword)
VALUES ('DBS', (29,'Feb',2000), SET('Suri','Smith'),
SET('Data Models','Databases', 'Transactions'))
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
54
Variant Data Types
(Tipos de datos variantes)
• Mencionamos anteriormente que la necesidad de
soportar nuevas formas de datos, tales como
multimedia, llevó a la introducción del concepto de
abstracción de objetos en el área de las bases de
datos.
• A continuación discutiremos tres nuevos tipos de
datos que los DBMS actuales en general no
soportan adecuadamente, para los cuales sin
embargo se espera soporte masivo en el futuro
cercano:
1. Multimedia Datatypes
2. Time-Series Data
3. Spatial Data
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
55
Multimedia Datatypes
• Los Tipos de Datos Multimedia incluyen imágenes, tales como
fotografías y gráficos, video clips, audio clips, tales como canciones
o mensajes de voz, y documentos, tales como libros y páginas html.
Estos tipos de datos fueron referidos anteriormente como BLOBs y
CLOBs.
• Dado su gran tamaño, los dos principales factores en la adecuada
administración de data multimedia son:
• Cómo Almacenar y Acceder eficientemente
• Cómo realizar extracciones basadas en el contenido (content-based
retrieval)
• Un query típico es localizar una fuente multimedia que contiene
objetos con ciertas características específicas. Por ejemplo, localizar
todos los video clips que incluyen un determinado edificio, o clips de
audio que incluyan una frase particular. En el caso de video clips, un
query podría involucrar una determinada actividad, tal como la foto
de la llegada a la meta en una carrera de autos, etc.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
56
Multimedia Datatypes
• De manera de soportar operaciones de recuperación
basadas en el contenido (content-based retrieval), se
requiere un modelo que pueda organizar e indexar datos
multimediales basado en sus contenidos.
• Identificar los contenidos en una fuente multimedia no es
simple. Algunas características matemáticas tipoespecíficas pueden ser extraídas automáticamente. Por
ejemplo, en un audio clip, características como
intensidad, claridad, amplificación, y otras puedes ser
extraídas automáticamente. Otras características
requieren la intervención humana, por ejemplo, la
identificación de un sonido que es placentero al oído.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
57
Multimedia Datatypes
• La principal técnica en la identificación de
características es aislarlas en un segmento de la
fuente. En el caso de imágenes, un segmento es una
región de celdas rectangulares adyacentes de un
determinado alto y ancho. En el caso de videos, un
segmento es un determinado número de frames
contiguos, identificado por sus frames de inicio y fin
en la fuente.
• Habiendo determinado la presencia de características
relevantes en un segmento, esta información puede
ser utlizada para indexar dicho segmento.
Diferentes estructuras de indexación han sido
propuestas para diferentes datos multimediales.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
58
Multimedia Datatypes
• Los Indices Clúster (Clustered Index) pueden ser
utilizados para agrupar segmentos que son similares.
Para estos propósitos, una función distancia entre
dos segmentos es definida en términos de un
conjunto de características. Si el valor resultante de
una distancia calculada es pequeño, entonces la
probabilidad de coincidencia es alta, por consiguiente
los segmentos son agrupados contiguos.
• La investigación de técnicas más eficientes y de
mejor calidad en la administración datos
multimediales es un área bastante activa dentro del
ámbito de las tecnologías emergentes y el manejo
de BLOBs y CLOBs.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
59
Time-Series Data
(Series de Datos Temporales)
• Las series de datos temporales representan un tipo
de colección especial que típicamente encontramos
en aplicaciones financieras y científicas.
• Es un set de valores, y cada valor es capturado en
un momento predefinido del tiempo.
• A modo de ejemplo, considere el precio de las
acciones de una determinada compañía al cierre del
mercado bursátil. Otro ejemplo es una secuencia de
valores registrados por un sensor cada
microsegundo durante un experimento nuclear.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
60
Time-Series Data
(Series de Datos Temporales)
• Los querys tradicionales sobre series temporales incluyen
“agregación temporal” sobre diferentes intervalos de tiempo.
La agregación temporal permite la abstracción respecto de la
unidad de medida de una operación sobre un intervalo de
tiempo.
• Por ejemplo, considerando que se posee la información del
precio de cierre diario, se desea encontrar el promedio
semanal del precio de cierre de las acciones, o el valor
máximo del mes. Otro ejemplo es el query que compara el
máximo precio de cierre mensual de este año, respecto del
año anterior.
• Un query más complejo es aquel que dada una colección de
movimientos mensuales de acciones, encuentre una serie de
tiempo que sea similar a una dada, o a alguna de
determinadas características.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
61
Time-Series Data
(Series de Datos Temporales)
• Los DBMS tradicionales no proveían ningún tipo de
soporte para la agregación temporal, y los querys
anteriores simplemente no estaban soportados.
Recientemente los DBMS comerciales han
comenzado a ofrecer extensiones para series
temporales y existe un esfuerzo de estandarización
para definir el TSQL (Temporal SQL) que soportará
series temporales.
• Actualmente las series temporales están soportadas
por DBMSs orientados a objeto a través de un tipo
de datos definido por el usuario.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
62
Spatial Data (Datos Espaciales)
• Los datos espaciales son objetos en un espacio multi-dimensional,
que encontramos típicamente en sistemas de información
geográficos (GIS).
• Las coordenadas geográficas, latitud y longitud, son dos
descriptores espaciales. Las bases de datos cartográficas utilizan
estas coordenadas para especificar la ubicación de ciudades, ríos,
carreteras, etc. Las bases de datos meteorológicas son
tridimensionales, ya que además de latitud y longitud, requieren
conocer la altura respecto de la tierra.
• Con el objeto de almacenar y consultar data espacial, se requiere
de modelos de datos espaciales que permitan representar e
interpretar estas características. Por ejemplo, en un espacio bidimensional geométrico, se requiere interpretar puntos, líneas,
segmentos, círculos, polígonos, etc. Las características espaciales
pueden ser estáticas, como la ubicación de un edificio, o dinámicas,
como un automóvil en movimiento.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
63
Spatial Data (Datos Espaciales)
• Con el objeto de ejecutar querys, se requerirá de operaciones
que permitan manipular las características espaciales. Por
ejemplo, se requiere de operadores que permitan calcular la
distancia entre dos puntos en un query de rango:
• Ej: Encontrar todas las estaciones de bencina 5 Km a la
redonda;
• otro operador que permita determinar qué objetos están más
cercanos a un punto determinado en un vecindario
• Ej: Encontrar la estación de bencina más cercana.
• También se requieren operadores para soportar join espacial o
superposición, que permitan testear si un objeto contiene a
otro, o bien si dos objetos se superponen.
 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA
64