tecnologias emergentes

1 2006 Universidad de Las Américas - Escuela de Ingeniería - Bases de Datos - APAD y JJAA

Tecnologías Emergentes de Bases de Datos

Unidad 10

Objetivos: Conocer las diferentes tecnologías emergentes en bases de datos y sus aplicaciones.

Emergent Database TechnologiesObjectives: Get introduced on emergent technologies in databases and their applications.


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ónIntroducció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 - 3Introducció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 - 4Introducció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 - 2ADBMS - 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 - 3ADBMS - 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ónEvento-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-Rules1. 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 Datos Complejas

Bajo nivel de soporte a estructuras de datos complejas.

Atributos Multivalor

Requiere la creación de nuevas entidades y relaciones.Pérdida de información sobre la estructura de los atributos.

BLOBs / CLOBsBajo nivel de soporte a grandes volúmenes de información binaria y de texto.

Jerarquía y Herencia

Requiere operaciones de join explícitas.No permite referencia a atributos “heredados” de una relación.

OperacionesTipo-Específicas

No provee soporte para la 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.LnameFrom MEMBER M, LIFE_MEMBER LFWhere 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, LnameFrom 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 Estructuras de

Datos

User-Defined Data Types and

Objects

Rutinas deManipulación

Específica

ADTs (Abstract Data Types)

Especificación Estructura de Datos Visible y

Operaciones Permitidas

Implementación de Estado, relaciones con otros ADTs

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

Base de Datos Objeto-Relacional

Extiende el modelo relacional con ADTs y objetos, estandarizada con SQL3 (o SQL99), la siguiente versión de SQL.

Base de Datos Orientadas a

Objetos

Extiende un lenguaje de programación orientado a objetos (típicamente C++ o Java), 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

Base de Datos

Orientadas a Objetos

Propuesto por el grupo ODMG (Object Database Management Group).

Estándar ODMG

OMG (Object Management Group), su iniciativa empuja por un modelo estándar cliente-servidor orientado a objetos denominado CORBA (Common Object Requester Broker Architecture)

Estándar OMG


• 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.

Object Relational Databases & SQL3


• 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');

Collection Types (colecciones)


• 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)

Tipos de Datos definidos por el usuario


• 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)))

User-Defined Types


• 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))

Row Types (Tipos de Filas)


• 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.

Type Inheritance (Herencia de Tipo)


• 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.

Table Inheritance (Herencia de Tabla)


• 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.

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))



• 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))



• 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

Querys y tipos de datos complejos


• 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

User-Defined Functions (Funciones definidas por el usuario)


• 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'))

Insertando Valores en estructuras complejas


• 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

Variant Data Types (Tipos de datos variantes)


• 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)

Multimedia Datatypes

• 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.



• 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 (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.



• 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.



• 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.

Spatial Data (Datos Espaciales)

tecnologias emergentes

Documents

Transcript of tecnologias emergentes