Bases de Datos I Cursada 2008 Clase 10: BD Post-relacionales Facultad de Ciencias Exactas Universidad Nac. Centro de la Pcia. de Bs. As. BASES DE DATOS I Sistemas relacionales: Fortalezas Base teórica Simplicidad y confiabilidad Apropiado para procesamiento on-line Soporte para independencia de datos Modelo de datos relacional satisfactorio para problemas “de negocios” Útiles para tipos de datos simples (fechas, strings), gran número de instancias (estudiantes, empleados), relaciones bien definidas entre datos, uso de ensambles, transacciones reducidas, queries simples BASES DE DATOS I Sistemas relacionales Inadecuados para: Aplicaciones CAD, CAM Objetos complejos y gráficos Gran número de tipos pero pocas instancias de cada tipo Diseño jerárquico pero no estático Aplicaciones específicas para: Ciclo de vida de desarrollo de software Diseño compartido en forma concurrente Documentación de código Ofimática y Sistemas Multimedia Soporte para e-mail y documentación Sistemas de Información Geográfica Información temporal-espacial (imág. satelitales, mapas) Reconocimiento de patrones 1 BASES DE DATOS I Sistemas relacionales: Otras desventajas La Normalización puede producir entidades que no se ajusten correctamente a las del mundo real Ensambles costosos Sobrecarga semántica Todos los datos se almacenan como tablas Tablas para entidades y también para relaciones Datos organizados según filas y columnas, aunque no todos los conceptos del mundo real pueden organizarse de esta forma. BASES DE DATOS I Sistemas relacionales: Otras desventajas Soporte insuficiente para restricciones de integridad y reglas del negocio Buen soporte para integridad referencial, de entidades y reglas del negocio simples NO para reglas complejas !! Estructura de datos homogénea Operaciones limitadas SQL no permite definir nuevas operaciones Dificultades para manejar consultas recursivas BASES DE DATOS I Sistemas relacionales: Otras desventajas Incompatibilidad (Impedance mismatch) Necesidad de empotrar SQL en otro lenguaje para obtener completitud computacional Los tipos de datos de SQL y de los lenguajes no coinciden !! Concurrencia, cambios de esquemas y acceso navegacional insuficiente No brinda soporte para transacciones de larga duración Dificultades para alterar los esquemas RDBMS están basados en acceso por contenido 2 BASES DE DATOS I Aplicaciones complejas y orientación a objetos Es necesaria la OO en estos casos? En los ‘80 se pensó que las aplicaciones complejas debía implementarse sobre sistemas OO PUROS!! Inicialmente esos sistemas fueron prometedores, pero finalmente no lograron cubrir las espectativas Una tecnología que combina lo mejor de los mundos relacional y OO DBMS objetorelacionales Sus principales ventajas: Escalabilidad masiva y características OO. BASES DE DATOS I Bases de Datos de Objetos Motivación superar las limitaciones del enfoque relacional: Modelos de datos más enriquecidos Mejor integración con los lenguajes de programación Tipos de BD con objetos: Objeto-relacional (Oracle, DB2, PostgreSQL). Centradas en Leng. de programación (Objectivity, FastObjects, Versant, ObjectStore). ORDBMS Soporta una forma de SQL extendida llamada SQL3 necesaria para soportar TDAs. Tiene corazón relacional porque los datos están almacenados en forma de tablas, SQL es el lenguaje de consulta utilizado y el resultado de una consulta es tabién una tabla. 3 BASES DE DATOS I Ventajas de los ORDBMSs Lenguaje de queries más expresivo Soporte para consultas navegacionales Soporte para métodos Soporte para evolución de esquemas Fuete acoplamiento entre los datos y las aplicaciones Generalización y herencia Soporte para transacciones de larga duración Aplicaciones avanzadas Mejoras en el desempeño RDBMS fuerza la serializabilidad CAD, CAM, GIS, etc. Para problemas de ingeniería BASES DE DATOS I Ventajas de los ORDBMSs Supera limitaciones de los RDBMS Reusar y Compartir extiende el servidor del DBMS para permitir la ejecución de la funcionalidad estándar en forma centralizada Funcionalidad compartida por todas las aplicaciones Evolución más que revolución !! SQL99 compatible y superador del actual SQL92 BASES DE DATOS I Ventajas de los ORDBMSs Capacidades para modelar enriquecidas Extensibilidad Puede modelarse estado y comportamiento Modela el mundo real más naturalmente Habilidad para construir nuevos tipos abstract data types No hay ‘impedance mismatch’ Se provee interfaz entre DML y lenguajes de programación computacionalmente completo 4 BASES DE DATOS I Desventajas de los ORDBMSs Complejidad acarrea incrementos en los costos asociados Se pierde la simplicidad y pureza del modelo relacional La mayoría de las aplicaciones no obtienen una performance optimal. Gap semántico entre la orientación a objetos y la relacional Las aplicaciones OO no son data-céntricas como las relacionales Los objetivos del SQL estándar inicial fueron: minimizar el esfuerzo del usuario y ser fácil de aprender BASES DE DATOS I Desventajas de los OODBMSs Falta un modelo de datos universal Falta de experiencia Uso limitado Orientado más a programadores que a usuarios típicos Falta de estándares RDBMSs basada en teoría de conjuntos OODBMSs no tiene una sólida base teórica ODMG evolución para modelos de datos estándar y lenguajes de consulta estándar Optimización de consultas compromete el encapsulamiento Necesidad de abrir el encapsulamiento para optimizar consultas acceso a atributos ‘private’ para acelerar queries BASES DE DATOS I Desventajas de los OODBMSs Bloqueos a nivel de objetos puede alterar la performance Complejidad Por ejemplo, bloquear cadenas de herencia caras Difíciles de usar Falta soporte para vistas Falta soporte para seguridad Concepto esencial en RDBMSs !! no hay vistas Granularidad primitiva Dificultades para garantizar derechos de acceso sobre clases y objetos individuales 5 BASES DE DATOS I Diferencias entre R, OO y OR Criterio RDBMS OODBMS ORDBMS Definición de Estándar SQL2 ODMG-2.0 SQL3 – SQL4 (en construcción) Soporte para características OO NO SI Limitado. Sólo para nuevos tipos de datos. Facilidad de Uso Fácil Fácil para programadores; algunos accesos SQL para usuarios finales. Fácil, salvo algunas de las extensiones Soporte para datos y relaciones complejas NO soporta TDA Soporta amplia variedad de tipos de datos y datos con interreelaciones complejas Soporta TDA y relaciones complejas. Performance MUY BUENA Regular MUY BUENA BASES DE DATOS I Diferencias entre R, OO y OR Criterio RDBMS OODBMS ORDBMS Madurez del Producto Muy maduro Relativamente maduro En proceso de evolución constante Uso de SQL Soporte absoluto OQL similar a SQL, con SQL3 incorpora caract. adiciones como objetos OO complejos y caract. OO Ventajas SQL, optimización de consultas y buena performance Aplicaciones complejas, Datos complejos, reusabilidad del código, consultas sobre ellos y menos código aplicaciones complejas. Desventajas Inhabilidad para aplicaciones complejas Baja performance por las dificultades en optimización, no soporta sistemas a gran escala. Baja performance en aplicaciones web. Soporte de proveedores Mercado de gran tamaño aunque los proveedores están migrando a ORDBMSs Mercado muy reducido por la amplia preeminencia de RDBMSs (actualmente ORDBMSs) Exitoso presente y futuro, los productores de RDBMS han migrado a este modelo. BASES DE DATOS I Una Matriz para clasificar aplicaciones en BD M. Stonebraker ideó una grilla de 4 casilleros para visualizar el mundo de las BD. Cuadrante inferior izquierdo: Cuadrante superior izquierdo: Aplicaciones con consultas complejas sobre datos simples. Cuadrante Inferior derecho: Aplicaciones que procesan datos simples y no necesitan consultas sobre datos. Aplicaciones con datos complejos pero con minimos requerimientos de consultas sobre ellos. Cuadrante superior derecho: Aplicaciones que requieren consultas complejas sobre datos elaborados. 6 BASES DE DATOS I Una Matriz para clasificar aplicaciones en BD Fuente: M. Stonebraker, Object-Relational Databases: The Next Great Wave BASES DE DATOS I Cuadrante 1: datos simples sin queries Ejemplo: procesadores de texto (word, ….) Información con mínima estructura interna. Actualización de documentos relativamente infrecuente. Documentos de tamaño razonable (no muy extensos). Las consultas se limitan a búsquedas de patrones y otras similares. BASES DE DATOS I Cuadrante 1: datos simples sin queries • Caso ejemplo: editor de texto • Base de Datos: file system 7 BASES DE DATOS I Cuadrante 2: datos simples con queries o Ejemplo: típica aplicación de negocios. o Información con estructura fija y sencilla. o El volumen de información puede ser importante. o El almacenamiento de la información debe ser confiable. o Consultas relativamente complejas. o Frecuentes actualizaciones y necesidad de mecanismos de seguridad. BASES DE DATOS I Cuadrante 2: datos simples con queries • Base de Datos: relacional • Estándar: SQL-99 create table empl ( nombre varchar (30), fecha-contrato date, sueldo float, depto varchar(20)); create table depto ( ndepto varchar(20), presupuesto float, piso int); 1. Obtener los nombres de los empleados del departamento de sistemas con salario de $3500 ó más. Select nombre from empl where depto = ‘sistemas’ and sueldo > 3500; BASES DE DATOS I Cuadrante 2: datos simples con queries Comentarios: Herramientas para el Cliente: 4GL, para disponer de forms para entrar datos y exhibirlos según sus necesidades. Performance: los mecanismos para transacciones, bloqueo P2F + write-ahead log (escritura anticipada del log) reduce performance !! Seguridad/arquitectura: cliente - servidor 8 BASES DE DATOS I Cuadrante 3: Datos complejos sin queries o Ejemplo: Aplicaciones CAD. o Información con estructura compleja. o Análisis de los datos complejo. o Volumen de información moderado. o Actualizaciones periódicas. BASES DE DATOS I Cuadrante 3: Datos complejos sin queries • Base de Datos: orientada a objetos • Estándar: ODMG create table empl ( nombre varchar (30), espacio polygon, adyacencia set-of empleado)); create table pisos ( numero int, ocupacion set-of espacio_ocupado); Objetivo: reubicar los empleados en los diferentes pisos, de acuerdo a espacios libres y ocupados main() { read all empl; read all pisos; compactar(); write all empl; } main() { compactar(); } BASES DE DATOS I Cuadrante 3: Datos complejos sin queries Comentarios: Performance: objetos persistentes pueden degradarla. Mercado: << BD relacional . 9 BASES DE DATOS I Cuadrante 4: Datos complejos con queries o Ejemplo: Archivo de imágenes. o Información de estructura compleja. o Puede incluir tipos de datos especiales. o Volumen de información significativo. o Se requieren consultas. o Actualizaciones periódicas. BASES DE DATOS I Cuadrante 4: Datos complejos con queries • Base de Datos: objeto-relacional • Estándar: SQL-99 Ejemplo: La Dirección de Turismo de Tandil (DTT) administra información sobre paseos, excursiones, lugares públicos y de recreación. Se han fotografiado estos recursos para documentarlos. Con el tiempo se han acumulado cerca de 500000 fotografías que son accedidas continuamente por los empleados. Naturalmente esta información debería poder ser accedida también por los turistas e interesados en general. Problema: clientes usualmente requieren una foto por contexto, por ejemplo ‘espejo de agua’ o ‘lugar para hacer montañismo’. Cómo encontrar fotos con este argumento de búsqueda? BASES DE DATOS I Cuadrante 4: Datos complejos con queries Create table fotos ( id int, fecha date, descripcion document, fotogr photo_CD_image); Create table punto-turistico ( nombre varchar(30), ubicacion point); 1. Encontrar los lugares a no más de 30km de Tandil, que tengan espejos de agua Select id from fotos F, punto-turistico PT, punto-turistico PT2 where espejodeagua (F.fotogr) and incluye (F.descripcion, PT.nombre) and PT2.nombre=‘Tandil’ and distancia (PT.ubicacion, PT2.ubicacion ) <= 30; 10 BASES DE DATOS I Cuadrante 4: Datos complejos con queries Comentarios: Lenguaje que permita escribir queries, funciones definidas por el usuario y operaciones (SQL-99). Herramientas para Cliente: herramientas avanzadas, por ej. “Zoom in/out”, etc. Performance: Optimizador de consultas, pues las funciones definidas por el usuario pueden ser costosas en tiempo. Ej: where espejodeagua(fotog) and fecha < ‘2006-01-01’ Seguridad/Arquitectura: cliente-servidor RDBMS 100 ORDBMS 150 File system OODBMS 1 BASES DE DATOS I Manifiestos de Bases de Datos de Nueva Generación Documentos cuyo objetivo es establecer fundamentos y direcciones de desarrollo de los DBMSs El primero, dedicado a los fundamentos de las bases de datos orientadas a objetos “Manifiesto de las bases de datos de tercera generación”, elaborado por el Comité para la Función de DBMSs Avanzados Atkinson, M.; Bancilhon, F.; DeWitt, D.; Dittrich, K.; Maier, D.; Zdonik, S. (1989). The Object-Oriented Database System Manifesto. Proceedings of the First International Conference on Deductive and Object-Oriented Databases, Kyoto, Japan, pp. 223-240. Stonebraker, M.; Rowe, L.; Lindsay, B.; Gray, J.; Carey, M.J.; Brodie, M.; Bernstein, P.; Beech, D. (1990). Third-Generation Database System Manifesto - The Committee for Advanced DBMS Function. SIGMOD Record 19(3). Pp. 31-44. En respuesta a la publicación de los anteriores, surge un documento fundacional elaborado por C. Date y H. Darwen Date, C.; Darwen, H. (1998). Foundation for Object/Relational Databases. The Third Manifesto. Reading, Mass. Addison-Wesley. BASES DE DATOS I Manifiesto de las bases de datos de tercera generación Características que deberían ser satisfechas por los sistemas de administración de datos de tercera generación, es decir postrelacionales. definición de un sistema de tercera generación Provisión de soporte para estructuras de objetos más ricas Facilidades para especificar conjuntos de reglas acerca de los datos, registros y colecciones 11 BASES DE DATOS I Manifiesto de las bases de datos de tercera generación: PRINCIPIOS 1. Las bases de datos de 3ª generación deberán soportar estructuras de objetos complejas y reglas. 1.1. sistema rico de tipos: arreglos, secuencias, registros, funciones, recursión. 1.2. herencia es una buena idea: simple y múltiple; subclases sin atrib. adicionales, sólo con restricciones de dominio. 1.3. encapsulamiento de funciones y procedimientos escritos en lenguajes de alto nivel es una buena idea: DBMSs de 2ª generación lo soportan en forma restringida: create, alter, drop… 1.4. identificadores únicos: en las BD de 2ª generación claves inteligentes; en las de 3ª generación claves surrogantes. 1.5. reglas (triggers y constraints): características principales de las BD de 3ª generación. BASES DE DATOS I Manifiesto de las bases de datos de tercera generación: PRINCIPIOS 2. Los DBMSs de 3ª generación deben tener todas las características y facilidades de los de 2ª generación. 2.1. todo acceso programado a la base de datos debe ser/ a través de un lenguaje de programación de alto nivel, no procedural. 2.2. al menos dos formas de expresar colecciones: por comprensión y por extensión. 2.3. deberá contar con vistas actualizables: actualización incremental, actualizaciones no ambiguas. 2.4. indicadores de performance no tienen conexión con el modelo de datos no deberían ser parte de él. BASES DE DATOS I Manifiesto de las bases de datos de tercera generación: PRINCIPIOS 3. Los sistemas de 3ª generación deben ser abiertos a otros sistemas. 3.1. accesibles por múltiples lenguajes de alto nivel DBMSs multilinguales. 3.2. persistencia en distintas variedades es una buena idea: modificación de los compiladores. 3.3 para bien o intergaláctico. para mal, SQL es el lenguaje 3.4. consultas y respuestas deberían ser el nivel más bajo de comunicación entre cliente y servidor. 12 BASES DE DATOS I SQL3 (SQL99, SQL1999) Nuevos tipos Nuevos predicados Operadores relacionales Reglas y triggers Tipos definidos por el usuario Capacidades para manejo de transacciones Rutinas almacenadas BASES DE DATOS I SQL3 Tipos definidos por el usuario (UDTs) Constructores de Tipo para tuplas (row), referencias (reference) y colecciones (arrays, sets, lists, multisets) Procedimientos definidos por el usuario, funciones y operadores Mecanismos para especificar identidad de objetos Mecanismos para encapsular operaciones Mecanismos para soportar herencia Soporte para grandes objetos pueden participar en relaciones supertipo/subtipo BLOBS y CLOBS BASES DE DATOS I Constructores de Tipo Tipo row: representa tipos de filas en tablas Sintaxis CREATE TYPE nombre_tipo_row AS [ROW] (<declaracion de componentes>) Ejemplo: CREATE TYPE Direccion AS ( calle VARCHAR (45), ciudad VARCHAR (25), CP CHAR (8)); 13 BASES DE DATOS I Constructores de Tipo CREATE TABLE Sucursal ( Nro VARCHAR(3), Domicilio ROW( calle VARCHAR(25), ciudad VARCHAR(15), CP ROW( prov VARCHAR(1) id_ciudad VARCHAR(4) codigo VARCHAR(3)))); INSERT INTO Sucursal VALUES(‘B5’, (‘San Martin’, ‘Tandil’, (‘B’,7000, ‘EHB’))); BASES DE DATOS I Constructores de Tipo Tipo array especifica que un atributo tendrá como valor una colección de valores Ejemplo: CREATE TYPE tipo_comp AS ( nombre_comp VARCHAR (2) ubicacion VARCHAR (20) ARRAY [10] ); Notación con punto (.): usada para los componentes: comp1.nombre_comp es la parte nombre_comp de comp1 (de tipo tipo_comp) BASES DE DATOS I Encapsulado de Operaciones Usuarios crean UDTs con nombre con sus propios métodos: CREATE TYPE <nombre_tipo> ( lista de atributos declaración de métodos EQUAL y de LESS THAN declaración de otros métodos ); 14 BASES DE DATOS I SQL3 UDTs Tipos abstractos de datos CREATE TYPE tipo_persona AS ( PRIVATE Fecha_nac DATE CHECK(Fecha_nac > DATE ‘1970-0101’); PUBLIC nombre VARCHAR(15) NOT NULL, apellido VARCHAR(15) NOT NULL, FUNCTION obtener_edad (P tipo_persona) RETURNS INTEGER RETURN /* codigo para calcular edad */ END; ... END) NOT FINAL; BASES DE DATOS I Sintaxis para Métodos Sintaxis: METHOD <nombre> (<lista_argum>) RETURNS <tipo>; Ejemplo CREATE TYPE Direccion AS ( calle VARCHAR (45), ciudad VARCHAR (25), CP CHAR (8) ) METHOD denom_catastral ( ) RETURNS CHAR(10); BASES DE DATOS I SQL3 (SQL4) User defined routines (UDR) Pueden definirse como parte de un UDT o como parte de un esquema Procedure, function o method Pueden escribirse en SQL o en un lenguaje de programacion externo Subtipos/supertipos Tablas No soporta múltiple herencia Una instancia UDT sólo puede persistir si es almacenada como una columna en una tabla 15 BASES DE DATOS I Ejemplo SQL3 Query SQL92, SQL3 (las extensiones que permiten manipular objetos) Ejemplos: SELECT p.apellido, p.obtener_edad FROM personal p WHERE p.es_director; SELECT p.apellido, p.direccion FROM personal p WHERE p.obtener_edad > 65; BASES DE DATOS I SQL3 Tipo Reference y OID Generado por el sistema, tipo REF Pueden usarse para definir relaciones entre tipos de filas Los tipos ‘reference’ identifican únicamente filas Permiten compartir las filas entre tablas Los ensambles complejos se ven reemplazados por simples expresiones de ‘caminos’ (paths) NO proveen integridad referencial !! Tipo Colección (Collection) ARRAYs, LISTs, SETs, MULTISETs BASES DE DATOS I SQL/PSM PSM = Persistent Stored Modules Especifica facilidades para particionar una aplicación entre un cliente y un servidor Minimiza el tráfico en la red, por lo tanto ofrece mejor desempeño Incluye Embedded SQL SQL/Temporal para manejar datos históricos 16 BASES DE DATOS I SQL3 Persistent Stored Modules SQL3 es computacionalmente completo Incluye: Asignación IF .. THEN .. ELSE .. ENDIF, y CASE REPEAT BLOCKS CALL y RETURN para invocar procedimientos Manejo de condiciones Triggers Eventos incluyen inserción, borrado y actualización de tuplas BASES DE DATOS I Herencia en SQL3 Se especifica mediante UNDER Ejemplo CREATE TYPE tipo-Manager UNDER tipo_Empl AS (depto_dirigido CHAR (20)); Tipo_Manager hereda todas las características de tipo_Empl Y tiene el atributo adicional depto_dirigido BASES DE DATOS I Otras operaciones y características WITH RECURSIVE para especificar queries recursivas Roles para especificar el nivel de autorización y privilegios Granularidad de los Triggers nivel de fila y de sentencia (row-level and statement-level) SQL3 soporta facilidades de lenguajes de programación 17 BASES DE DATOS I Resumen A pesar de que los ORDBMS tratan de extender los RDBMS con conceptos OO, aún falta soporte para modelos transaccionales avanzados. No hay una única extensión del modelo relacional y el grado de extensión varía. Diseño de BD Objeto-relacionales Más complicado Procesamiento y optimización de consultas Interacción de reglas con transacciones BASES DE DATOS I En la actualidad … Principal fuerza motora de la migración a ORDBMSs los desafíos que presentan las nuevas aplicaciones: Texto Imágenes Audio Flujo de datos BLOBs (binary large objects) BASES DE DATOS I Problemas con la Clasificación La mayoría de los OODBMSs exigen compartir el cuadrante de los ORDBMSs. 18 BASES DE DATOS I Mito: OODBMS no tienen soporte para consultas BASES DE DATOS I DBMSs y Mercado RDBMS 100 ORDBMS 150 File system OODBMS 1 19