SGBD orientados a objetos

Basado en el curso del Dr. Jose Luis Zechinelli Martini, UDLAP.

SGBD relacionales (SGBDR)

Más de 20 años de usar SGBD relacionales en la industria: prototipos (75) y productos (80).

Modelo simple (tablas), programas y datos separados.

Bases teóricas sólidas: Relaciones n-arias R D1 D2 ... Dn. Soporte matemático: álgebra y calculo relacional. Dependencias funcionales (semántica de la relación).

Tecnología madura: Optimización de consultas, Indexación, Administración de la concurrencia y de transacciones (ACID).

SGBDR (2)

Seguridad en el funcionamiento: recuperación.

Acceso transparente a los datos: persistencia sistemática.

Lenguaje SQL: Lenguaje declarativo (especificar el qué y no el cómo). Estándares: SEQUEL (76), ANSI SQL (86), SQL1 (89), SQL2 (92),

SQL3.

Herramientas para el desarrollo de aplicaciones: SQL / REPORT, SQL /FORMS.

SGBD relacionales distribuidos (SQL server).

Debilidades de los SGBDR

Semántica pobre (modelo plano): Tipos de datos: alfanuméricos y restricciones de integridad. Datos sin operaciones: procedimientos no almacenados.

Ausencia de extensibilidad: No hay tipos del usuario (tipos complejos). Funciones del SGBD (caja negra cerrada).

Lenguaje de manipulación de datos “incompleto”: SQL es un lenguaje de consulta. SQL no es un lenguaje de programación.

Problemas de impedancia entre LMD y los lenguajes de programación: Declarativo vs. procedural. Conjuntos vs. elementos (conversiones).

Lenguajes de programación (LP)

Datos y programas integrados: unidad de trabajo write (no hay manejo de transacciones).

Un solo nivel de abstracción vs. Niveles interno y externo (Arquitectura ANSI / SPARC).

Lenguaje completo desde el punto de vista de la máquina de Turing.

LP (2)

Lenguajes expresivos: modularidad, herencia, tipos, etc.

Administración de la memoria central: optimización de código, administración de la memoria cache, garbage collector, etc.

Persistencia de la memoria (variables) en bloques y acceso a estos bloques por escritura y lectura explicita.

LP vs. LMD

Inconvenientes: Dos lenguajes a aprender. Dos estilos de programación. Conversiones de datos entre la base y el espacio de trabajo del

programa. Escoger entre las operaciones del SGBD y las del programa. Comunicaciones frecuentes entre los procesos cliente y servidor.

Solución: SGBD OO (objetos del disco a la pantalla). Datos + comportamiento. Lenguaje de consultas: OQL.

Bases de datos OO

Conceptos OO aplicadas sobre las bases de datos.

No hay teoría o apoyo matemático (salvo la teoría del LP).

Orígenes: IA (modelos centrados en objetos: frame, facets). LP OO: Smalltalk, Modula, ADA, LISP+, C++, EIFFFEL, etc. BD (objeto, entidad) y modelos semánticos (relaciones de

herencia, generalización, composición, etc.).

Reglas de oro

Reglas de base:

Persistencia.

Manejo de disco.

Fiabilidad, seguridad.

Compartir datos.

Consulta ad-hoc.

Reglas SGBD OO:

Objetos complejos (ID).

Tipos o clases.

Encapsulación.

Herencia.

Sobre carga y ligado dinámico.

SGBD completo y extensible.

Acoplamiento de LP y SGBD

Punto de vista LP: Lenguajes de programación persistentes o BD. Sistemas: Galileo, PS-Algol, Adaplex, Napier88, Pjama, etc.

Punto de vista BD: Lenguaje de programación OO + BD. Sistemas: Gemstone, ORION, Itasca, O2, Versant, Poet,

Jasmine, etc.

Extensión del modelo relacional

SGBD relacionales extendidos: Principios del relacional + valores complejos. Sistemas: VERSO, ORACLE, ILLUSTRA, UniSQL, etc.

SGBD deductivos: Principios del relacional + lógica de primer orden. Sistemas: RDL, LDL, NAIL, etc.

SGBD extensibles: Principios del relacional + administración de módulos. Sistemas: Exodus, Genesis, etc.

Plan

Introducción

Modelos Modelo de datos (estructura, parte estática) Modelo de comportamiento (operaciones, parte

dinámica) Modelo de nombres (puntos de entrada en la BD) Modelo de persistencia (datos persistentes o no)

Programación de aplicaciones

Object Database Management Group (ODMG) (1)

Grupo de desarrollo de SGBD orientados a objetos

Ligado (más o menos) a la OMG (Object Management Group)

Creado a mediados de 1991 para definir los estándares de las BD orientadas a objetos

Aparición de “The ODMG-93 Standard”

Revisiones ODMG 95, 97, 99 (ODMG 3.0 + Java)

Object Database Management Group (ODMG) (2)

Object Design, Sun Microsystems, ONTOS, O2, Technology / Ardent Soft., Objectivity, Versant, Gemstone, Computer Associates, ObjectStore, InterSystems CACHE, etc.

Asegurar una portabilidad sobre los diferentes productos de estas compañías

Normalizar el modelo de datos a objetos y los lenguajes

ODMG-93, 95, 97 (v 2.0), 99 (v 3.0)

Object Model

Object Data Definition Language (ODL)

Object Manipulation Language (OML)

Object Query Language (OQL)

Interfaces con C++, Smalltalk, Java

Modelo de datos Objetos complejos: atómico, tuple, bags, sets, lists, ...

Asociaciones entre objetos (1:1, 1:N, N:M)

Identificador de objeto: independencia del valor, referencia, compartir

Clase / tipo: caracterizar los objetos de la misma naturaleza

Herencia: especialización – relación “is a” (“es un”), orden parcial sobre los tipos / clases

Independencia lógica, física

Objeto

Encapsulación: métodos r_name, w_name, etc. Valor es privado y puede ser complejo: tuple, set, list Identificador único: p1, v1, v2, v3 Métodos = interfaz del objeto Les objetos reciben mensajes y ejecutan operaciones

p1

tuple(name: "France", capital: v1, towns: set(v1, v2, v3) )

r_name

w_name

r_capital

add_town

...

Ejemplo de un valor complejo

struct ( name: "Dupont",first_names: set<"Jean", "Jules", "Gaston">,

birth_date: 490711, address: struct ( number:13,

street: "chemin de la Vigne", zip_code: 38240, town: "Vienne“ ) )

struct ( name: string, first_names: set<string>, birth_date: integer, address: struct ( number:integer, street: string, zip_code: integer, town: string ) )

Objetos y valores

Objeto con un valor complejo

Identificador de objeto

(i, atom) i.e. integer, float, bit, char, string, … (i, tuple(a1: i1, a2 : i2, ... an : in)) (i, set( i1, i2, … in)) (i, list(i1, i2, … in))

list

struct

atom

set

Identificador de objeto

Referencia única: cada objeto tiene un identificador único para toda su vida:

El identificador es independiente del valor. Permite compartir los objetos.

El identificador es un valor que permite identificar los objetos y crear grafos de composición (permitiendo ciclos).

Identidad e igualdad son dos conceptos diferentes.

Objetos

Un objeto que representa a Francia:

(p1, struct( name: “France”,capital: v1,towns: set<v1, v2, v3>)

(v1, struct( name: "Paris", town_state: p1, population: 9000000))

(v2, struct( name: "Lyon", town_state: p1, population: 1260000))

(v3, struct( name: "Grenoble", town_state: p1, population: 400000))

Grafo de composición de objetosp1

"France" set( • , • , • )

name towns

capital

"Paris" 9 000 000

town_statepopulation

v1

"Grenoble"400000

name

v3

"Lyon" 1 260 000

v2

population

population

town_state

town_state

name

name

Clase

Objeto es una instancia de una clase Valor es una instancia de un tipo Métodos de clase

Country

tuple(name: string, capital: Town, towns: set(Town) )

r_name

w_name

r_capital

add_town

...

Tipo

Tipos atómicos: integer ( 1, 36, -267 ) real ( 3.14159, -6.4E12 ) char (‘A’) string ( “buenos días“ ) boolean (true) y (false) bits (0, 1) nil

Constructores: struct, list, set, unique set

Tipos predefinidos: date, time, interval, timestamp

Grafo de composición de clases

class Countrystruct( name: string, capital: Town, towns: set<Town> ) …end;

class Townstruct( name: string, town_state: Country, population: integer ) …end;

Town

Country

ODMG: Object Model (1)

OBJECT: caracterizado por un tipo (INTERFACE) que le asocia un estado y un comportamiento. Un objeto es una instancia de una clase.

Estado: definido por un conjunto de valores que el objeto lleva en sus propiedades (atributos, y / o varios otros objetos). Los valores de las propiedades pueden cambiar a lo largo del tiempo.

Comportamiento: definido por un conjunto de operaciones ejecutables sobre el objeto.

Bases de datos: interfaces y clases definidas en ODL y objetos.

ODMG: Object Model (2) Un tipo tiene una especificación externa (propiedades, operaciones,

excepciones) y una o varias implantaciones (aspectos internos).

INTERFACE: especificación abstracta del comportamiento.

CLASE: especificación abstracta del comportamiento y del estado.

INTERFACE CLASS Literal

Operaciones Estado (Propiedades)

ODMG: Objeto

Un objeto tiene un identificador único (en una base)

Atomic_object definido por el usuario

Collection_object de tipo:set<t>, bag<t>, list<t>, array<t>, dictionary<t>

t puede ser un tipo de objeto o de literal

Structured_object

Date, Interval, Time, TimeStamp

ODMG: LiteralUna Literal (valor) no tiene identificador. No es en general referenciable y está incluida en un objeto.

Atomic_literal:

long, float, boolean, char, string, short, octet, etc.

Collection_literal:

set<t>, bag<t>, list<t>, array<t>, dictionary<t>

Structured_literal:

date, interval, time, timestamp

Structure:

struct Address { unsigned short num;

string street; string city }

ODMG: Jerarquía de tiposTipo Literal

Atomic_literal long, short float char string boolean enum<>

Collection_literal set <> bag <> list <> array <> dictionary <>

Structured_literal date time timestamp interval structure <>

Tipo Objeto

Atomic_object Collection_object

Set <> Bag <> List <> Array <> Dictionary <>

Structured_object Date Time Timestamp Interval

Nota: Atención con date, Date

ODMG: Interfaz

interface Student-IF {attribute string name;attribute string student_id;attribute Address address;

relationship Set<Section> takes inverse Section::is_taken_by; boolean register_for_course(in unsigned short course,

in unsigned short Section) raises (unsatisfied_prerequisites, section_full, course_full)}

Student-IF define por una interfaz que especifica:

- los atributos (abstractos)

- las relaciones (o ligas) con otros tipos de objetos

- las operaciones

ODMG: Atributo

Toma por valor una literal

Un atributo tiene un nombre y un tipo (de valores) asociados

No forzosamente almacenado

Ejemplo: atributo short edad en una interfaz significa que puede ser almacenado o calculado ... instrumentado como método

No hay referencia a través de los atributos

ODMG: Asociaciones

Un objeto puede ser ligados con otros objetos a través de relaciones

Relaciones binarias y bi-direccionales 1-1, 1-N, N-M

Relación: par de encabezados con nombres de tipos y funciones de acceso en los dos sentidos

teaches en Professor y is_taught_by en Section funciones inversas una de otra

El sistema administra la integridad referencial

Section Professoris_taught_by

teaches

ODMG: Clase (1)

Class Professor {

attribute string name;

attribute integer faculty_id;

attribute Salary annual_salary;

attribute enum Rank{full, associate,assistant} rank;

relationship Set<Section> teaches inverse Section::is_taught_by;

...

}

Estructuras de datos para la representación de las instancias.

Métodos que operan sobre estas estructures de datos.

ODMG: Clase (2)

Class Section {

attribute string number;

relationship Professor is_taught_by inverse Professor::teaches;

...

}

struct Salary {

float base;

float overtime;

float bonus;

}

Ejercicio

Bases de datos de películas, estrellas, estudios ... algunos elementos.

Cada película tiene un título, un año de fabricación, un tiempo (minutos), tipo (color, blanco y negro, etc.), tiene actores, pertenece a un estudio, etc.

Cada estrella tiene un nombre, una dirección y un role en la película, ...