Tecnologias Emergentes

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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
• 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”
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.
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.
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.
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”.
Limitaciones del Modelo
Relacional
Estructuras de Bajo nivel de soporte a estructuras de
Datos Complejas datos complejas.
Requiere la creación de nuevas entidades

Atributos y relaciones.
Multivalor
Pérdida de información sobre la estructura
de los atributos.
Bajo nivel de soporte a grandes

BLOBs / CLOBs
volúmenes de información binaria y de
texto.
Jerarquía y Requiere operaciones de join explícitas.

Herencia No permite referencia a atributos
“heredados” de una relación.
Operaciones
No provee soporte para la
Tipo-Específicas especificación y construcción de
operaciones tipo-específicas.
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.
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
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.
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)
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.
Complejas Rutinas de User-Defined

Estructuras de Manipulación Data Types and
Datos Específica Objects
ADTs (Abstract Data Types)
Especificación Estructura Implementación de Estado,

de Datos Visible y relaciones con otros ADTs
Operaciones Permitidas y sus operaciones
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.
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
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.
Tendencias
Extiende el modelo relacional con ADTs y

objetos, estandarizada con SQL3 (o SQL99),
Base de Datos
Objeto-Relacional
la siguiente versión de SQL.
Extiende un lenguaje de programación

Base de Datos
orientado a objetos (típicamente C++ o Java),
Orientadas a
Objetos con conceptos propios de bases de datos.
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.
Tendencias
Propuesto por el grupo ODMG

Estándar ODMG (Object Database Management
Base de Group).
Datos
Orientadas OMG (Object Management Group),
a Objetos su iniciativa empuja por un
Estándar OMG modelo estándar cliente-servidor
orientado a objetos denominado
CORBA (Common Object
Requester Broker Architecture)
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.
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)))
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');
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)
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)))
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))
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
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.
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
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.
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.
• 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,
authors LIST(REF(Person)),
PRIMARY KEY (title))
• 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,
authors LIST(REF(people_row)),
SCOPE FOR authors IS Person,
PRIMARY KEY (title))
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
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
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
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
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'))
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
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.
• 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 tipo-
especí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.
• 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.
• 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.
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.
Time-Series Data
• 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.
Time-Series Data
• 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.
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 bi-
dimensional 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.
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.

Tecnologias Emergentes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tecnologias Emergentes

Uploaded by

Copyright:

Available Formats

Unidad 10

Emergent Database Technologies

• Revisaremos las principales tecnologías

– Bases de Datos Activas

en las últimas versiones de algunos DBMS y en

• Pretende responder a las necesidades de

• Todas estas nuevas tecnologías

• Por otra parte, también se establece el

• Los sistemas de bases de datos activas

• En otras palabras, todos los DBMS futuros, sean

• Una base de datos puede considerarse

2. Un ADBMS contiene un modelo ECA-Rule:

– 2.a. Un ADBMS debe proveer funcionalidad

• Un tipo de evento describe las situaciones a las

2.b. Un ADBMS debe proveer funcionalidad para la

2.c. Un ADBMS debe proveer funcionalidad para la

3. Un ADBMS debe soportar administración

3.a.El set de reglas debe ser administrado por el ADBMS,

3.b. El ADBMS debe proveer capacidad para que el set de

3.c.El ADBMS debe soportar la habilitación y deshabilitación

Variaciones de las reglas ECA:

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

• Orientado al conjunto: cuando un evento ocurre, la

4.c. Un ADBMS debe ser capaz de evaluar condiciones, la

4.d. Un ADBMS debe ser capaz de ejecutar acciones: una

Los modos de acoplamiento originalmente propuestos son:

En los 2 primeros casos, la transacción invocada es en la práctica

• Un ADBMS debe implementar “modos de

Si el ADBMS soporta eventos compuestos, debe

7. Un ADBMS debe administrar historia de eventos o

8. Un ADBMS debe implementar resolución de

Por la naturaleza de los sistemas de información, puede

9. Un ADBMS debe soportar un ambiente de

Por definición el uso de un ADBMS debe suponer que la

Requiere la creación de nuevas entidades

Bajo nivel de soporte a grandes

Jerarquía y Requiere operaciones de join explícitas.

• Dos de las primeras limitaciones del modelo

• Como resultado la información sobre la

• Debido a que el modelo relacional no permite expresar directamente

• Los DBMS relacionales soportan el uso de strings de bits y

• Similar situación se presenta en objetos de

Tipos de Datos y Objetos defindos

(User-Defined Data Types and Objects)

• Los problemas que surgen con el manejo de BLOBs y

Complejas Rutinas de User-Defined

ADTs (Abstract Data Types)

Especificación Estructura Implementación de Estado,

Un ADT consiste en:

Herencia de Estado y Operaciones

Si un ADT es utilizado para definir una columna, entonces las

• La introducción a ADTs y objetos como medio de soporte

Extiende el modelo relacional con ADTs y

Extiende un lenguaje de programación

• Un estándar de modelo de datos orientado al objeto

Propuesto por el grupo ODMG

• Los tipos colección (collection types) permiten la definición de

• 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