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 Programación de aplicaciones 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

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 list struct atom set Objeto con un valor complejo Identificador de objeto

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", population: 1260000)) (v3, struct( name: "Grenoble", population: 400000))

Grafo de composición de objetos

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

Tipo Tipos atómicos: Constructores: struct, list, set, unique set 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 Country struct( name: string, capital: Town, towns: set<Town> ) … end; class Town town_state: Country, population: integer ) 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: Literal Una 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 tipos Tipo 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 Student-IF define por una interfaz que especifica: 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 Professor is_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, ...