Bases de Datos I. Cursada Clase 10: BD Post-relacionales. Sistemas relacionales: Fortalezas. Sistemas relacionales BASES DE DATOS I

Transcripción

1 Bases de Datos I Cursada 2008 Clase 10: BD Post-relacionales Facultad de Ciencias Exactas Universidad Nac. Centro de la Pcia. de Bs. As. 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 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 y documentación Sistemas de Información Geográfica Información temporal-espacial (imág. satelitales, mapas) Reconocimiento de patrones 1

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

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

4 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 RDBMS fuerza la serializabilidad Aplicaciones avanzadas CAD, CAM, GIS, etc. Mejoras en el desempeño Para problemas de ingeniería 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 Ventajas de los ORDBMSs Capacidades para modelar enriquecidas Puede modelarse estado y comportamiento Modela el mundo real más naturalmente Extensibilidad 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

5 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 Desventajas de los OODBMSs Falta un modelo de datos universal RDBMSs basada en teoría de conjuntos OODBMSs no tiene una sólida base teórica Falta de experiencia Uso limitado Orientado más a programadores que a usuarios típicos Falta de estándares 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 Desventajas de los OODBMSs Bloqueos a nivel de objetos puede alterar la performance Por ejemplo, bloquear cadenas de herencia Complejidad caras Difíciles de usar Falta soporte para vistas Concepto esencial en RDBMSs!! Falta soporte para seguridad no hay vistas Granularidad primitiva Dificultades para garantizar derechos de acceso sobre clases y objetos individuales 5

6 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 Soporte para datos y relaciones complejas Performance Fácil NO soporta TDA MUY BUENA Fácil para programadores; algunos accesos SQL para usuarios finales. Soporta amplia variedad de tipos de datos y datos con interreelaciones complejas Regular Fácil, salvo algunas de las extensiones Soporta TDA y relaciones complejas. MUY BUENA 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 Ventajas Desventajas Soporte de proveedores Soporte absoluto SQL, optimización de consultas y buena performance Inhabilidad para aplicaciones complejas Mercado de gran tamaño aunque los proveedores están migrando a ORDBMSs OQL similar a SQL, con SQL3 incorpora caract. adiciones como objetos OO complejos y caract. OO Aplicaciones complejas, Datos complejos, reusabilidad del código, consultas sobre ellos y menos código aplicaciones complejas. Baja performance por las dificultades en optimización, no soporta sistemas a gran escala. Mercado muy reducido por la amplia preeminencia de RDBMSs (actualmente ORDBMSs) Baja performance en aplicaciones web. Exitoso presente y futuro, los productores de RDBMS han migrado a este modelo. 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: Aplicaciones que procesan datos simples y no necesitan consultas sobre datos. Cuadrante superior izquierdo: Aplicaciones con consultas complejas sobre datos simples. Cuadrante Inferior derecho: Aplicaciones con datos complejos pero con minimos requerimientos de consultas sobre ellos. Cuadrante superior derecho: Aplicaciones que requieren consultas complejas sobre datos elaborados. 6

7 Una Matriz para clasificar aplicaciones en BD Fuente: M. Stonebraker, Object-Relational Databases: The Next Great Wave 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. Cuadrante 1: datos simples sin queries Caso ejemplo: editor de texto Base de Datos: file system 7

8 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. 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; Comentarios: Cuadrante 2: datos simples con queries 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

9 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. 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(); } Comentarios: Cuadrante 3: Datos complejos sin queries Performance: objetos persistentes pueden degradarla. Mercado: << BD relacional. 9

10 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. 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 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? 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

11 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 < Seguridad/Arquitectura: cliente-servidor RDBMS 100 File system ORDBMS 150 OODBMS 1 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 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 Manifiesto de las bases de datos de tercera generación, elaborado por el Comité para la Función de DBMSs Avanzados 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 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. 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

12 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 sistema rico de tipos: arreglos, secuencias, registros, funciones, recursión herencia es una buena idea: simple y múltiple; subclases sin atrib. adicionales, sólo con restricciones de dominio 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 reglas (triggers y constraints): características principales de las BD de 3ª generación. 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 todo acceso programado a la base de datos debe ser/ a través de un lenguaje de programación de alto nivel, no procedural al menos dos formas de expresar colecciones: por comprensión y por extensión deberá contar con vistas actualizables: actualización incremental, actualizaciones no ambiguas indicadores de performance no tienen conexión con el modelo de datos no deberían ser parte de él. Manifiesto de las bases de datos de tercera generación: PRINCIPIOS 3. Los sistemas de 3ª generación deben ser abiertos a otros sistemas accesibles por múltiples lenguajes de alto nivel DBMSs multilinguales persistencia en distintas variedades es una buena idea: modificación de los compiladores. 3.3 para bien o para mal, SQL es el lenguaje intergaláctico consultas y respuestas deberían ser el nivel más bajo de comunicación entre cliente y servidor. 12

13 SQL3 (SQL99, SQL1999) Nuevos tipos Nuevos predicados Operadores relacionales Reglas y triggers Tipos definidos por el usuario Capacidades para manejo de transacciones Rutinas almacenadas SQL3 Tipos definidos por el usuario (UDTs) pueden participar en relaciones supertipo/subtipo 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 BLOBS y CLOBS 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

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

15 UDTs SQL3 Tipos abstractos de datos CREATE TYPE tipo_persona AS ( PRIVATE Fecha_nac DATE CHECK(Fecha_nac > DATE ); 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; 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); 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 No soporta múltiple herencia Tablas Una instancia UDT sólo puede persistir si es almacenada como una columna en una tabla 15

16 Query Ejemplo SQL3 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; 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 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

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

18 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 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) Problemas con la Clasificación La mayoría de los OODBMSs exigen compartir el cuadrante de los ORDBMSs. 18

19 Mito: OODBMS no tienen soporte para consultas DBMSs y Mercado RDBMS 100 File system ORDBMS 150 OODBMS 1 19