Bases de Datos I Cursada 2008 Clase 10: BD Post

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